I have successfully built a Java web application using TFS's java support via ant. My problem is that I have several applications that share a common build process and would like to reuse the build.xml (with parameters passed in to differentiate the output), however, the TFS Build Definition does not allow me to reference a build.xml file that is in a shared location outside of the workspace mapping for my particular build.
For example, assuming the following Version Control structure:
Source
Applications
Application 1
Main
src
WebContent
Application 2
Main
src
WebContent
For each build definition I would like root to be that of the Main branch of that application so that only those source files are copied to the build server. I would like the build.xml to be stored in, say, Applications directory as it will be shared across Application 1 and Application 2. When I try this I get the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\BuildExtensions\Microsoft.TeamFoundation.Build.Extensions.Ant.targets (306): There is no working folder mapping for $/Source/Applications/build.xml
This is because my Source Control Folder in the build definition is set to a child folder (Main). If I set my Source Control Folder to be the Applications folder, I believe it will work, however, I then notice that the build attempts to transfer ALL files under Applications to the build server which slows the build down to a crawl. Any thoughts on how I can achieve the desired reuse? Perhaps something in the TFSBuild.proj file that would restrict the files that get transferred using a parameter ${ApplicationName}/Main or something like that?
Thanks in advance for any assistance.
You can set up you workspace to include folders and cloak others. I can imagine that it would be arouse work to cloak all of the other stuff in scope. A recommended practice would be to have the shared folder under its own folder rather than the root of applications. That way you can map that folder explicitly as well as the branch that you want to build.
When the XAML builds are retired at launch of TFS 2015 the new build system allows you to have tasks that are shared between build definitions.
Related
I currently have a large Java program built using Swing and I am exploring the possibility of migrating to JavaFX. I am particularly interested in the ability to support native packaging since my current configuration involves simply double-clicking an executable JAR file and I find that many of my users are confused by this. Here is my problem: my program uses a plugin architecture in which, upon launching, it discovers various tools contained in JAR files and Groovy scripts. Because the end user can add their own tools by adding their own JAR library or script file the tools must exist in a folder outside of my main JAR. The folder must be discoverable by the end-user such that they could add/modify these files themselves. Here is my current configuration:
./ - the root of the program
|__ main.jar
|__ Resources folder containing JAR libraries and script files
This flexible configuration also allowed for the program to simply be copied into new locations without requiring a proper setup. So, I ask, is there any way of maintaining this type of open configuration while using the native packaging utilities that are now available? Would I need to create a resources folder outside the location of the JAR itself during some kind of setup? If this is the case, how do I go about doing this?
I have recently moved a webapp I have been developing to a new machine running 64bit Eclipse Helios (Service Release 2) and I am using Maven plugin M2Eclipse.
I have deployed on a local tomcat install through Eclipse and everything is ok (more or less), but I want to select the option "Serve Modules without publishing", but when I select this option I get errors:
log4j:ERROR Could not read configuration file from URL [file:/C:/butterfly/svn/trunk/micro/src/main/webapp/WEB-INF/classes/log4j.properties].
java.io.FileNotFoundException: C:\butterfly\svn\trunk\micro\src\main\webapp\WEB-INF\classes\log4j.properties (The system cannot find the file specified)
The log4j.properties file is not there, as in my source directories in lives in src/main/resources - at build it then gets copied over to target/WEB-INF/classes/..
Eclipse seems to be mixing the expected target directory with the src directory so not finding it.
Im not sure if this is happening for just the properties file or if the same problem will occur looking for all built resources.
I have seen these issues:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318449
http://www.eclipse.org/forums/index.php?t=msg&goto=661045&S=25bafd85b11e042c169ecf1752bfa479
but they seem to be slightly different or already fixed (My Helios is a new download from last weekend)
Anyone experience this or know how to resolve?
From here: "The Serve modules without publishing option does what it says. Web content will be served directly from the "WebContent" folder of the Dynamic Web Project. A customized context is used to make the project's dependencies available in the Web application's classloader". I would expect eclipse to emulate serving every class / resource file (including log4j.properties) from WEB-INF/classes after you build the project. As a workaround, what about creating a "classes" folder inside WebContent, copy log4j.properties file here and see if the classloader gets happy?
I'm building an Android application (as an Eclipse project) that needs to access a web service. We will be sending the data from the service as JSON serialized classes, so we want to share some of the classes between the Android application and the server application. We are currently thinking that the way we need to do this is to structure our Git repository with 3 folders. One for the client, one for the server, and one for the shared library.
But at that point we couldn't figure out how to create the shared code. It looks like we can put all the .java files into a folder and then create a relative link to that folder from the other projects, but is that a good way to go about this?
The other possibility we found was to create another project in Eclipse and then include the library project in the client project. However we ran into a problem here. How can we make the library usable by both the server and Android? If I create a new Java project in Eclipse, I must select a JRE to build for, but Dalvik isn't an option, and even if it was how could I use the library with a desktop VM if the library was compiled for Dalvik?
I would use 3 projects:
server
shared
client (android)
and include shared as a project dependency in both server and client. If you use ant you'd drop the shared.jar in both server/lib and client/lib every time it's changed, and if you use maven it's a dependency (possibly with Ant + Ivy it's also a dependency). Consider Nexus as a repository location in that case.
You don't actually need to create a separate Eclipse project for the shared classes. You can just create a 'common source folder' outside of the other two projects' disk hierarchy. For both the server and client projects :in the Properties/Java Build Path/Source add a 'Link source' to the new folder. (Perhaps this is what you meant by 'relative link'). It's easy to add this common source folder to an Ant build file.
You could add the path to the classes/JARs to the server's runtime classpath.
Since it's unclear which one you're using, here's just a generic answer based on Apache Tomcat.
Open /conf/catalina.properties file.
Edit shared.loader entry to include the path to the package root of those classes or JAR file(s).
E.g.
shared.loader = /path/to/classes
or
shared.loader = /path/to/specific.jar
or
shared.loader = /path/to/*.jar
You can even specify multiple paths separated by a comma.
I am using ClearCase in my application which generates a whole load of ".copyarea.db" files (one in every folder).
These cause conflicts when publishing to Tomcat as Eclipse will bundle the "classes" and "test-classes" folders into one JAR (not sure why it does this - as there is no need to have test classes available on the application server).
Any folders with the same names will have a separate .copyarea.db in the classes and test-classes branches.
I managed to get around this problem in general by adding ".copyarea.db" to the Filtered resources on the Java->Compiler->Building->Output Folder preference page. This stops the file appearing in source output (package/class folders), the vast majority of cases.
However there remains the problem of the root folder, i.e. "target/classes/.copyarea.db" and "target/test-classes/.copyarea.db".
These files are not filtered as they are not part of the compile task.
Just deleting the files manually doesn't help either, as Eclipse expects to find them and doesn't.
How can I exclude these ".copyarea.db" files from the root "classes" and "test-classes" folders?
This file .copyarea.db is created in each directory of a web view (through CCRC, the remote client of ClearCase).
The simplest solution would be to not put under source control the directories classes and test-classes.
Then, as illustrated by this technote:
Otherwise, the directory should not be controlled.
If the directory is not controlled, then the .copyarea.db file within it should never be created.
If the directory was accidentally added to source control, this could be prevented in the future by adding classes to the ignore list. This would avoid the directory being passed to ClearCase during the Share.
Since you don't usually version the binaries produced under classes and test-classes, removing those folder, and adding them again manually (keeping them private to your view) is an acceptable solution.
If those folders are not under version control, then those copyarea.db come from versioned folders which contain them, and have been copied to the destination folder.
In that case, you can simply remove the copyarea.db files.
But since you said that Eclipse "expects to find them and doesn't", I assume those "classes" and "test-classes" folders are not private folder.
concerning
These cause conflicts when publishing to Tomcat as Eclipse will bundle the "classes" and "test-classes" folders into one JAR (not sure why it does this - as there is no need to have test classes available on the application server)
you can configure this in project properties, build path, order and export, or use maven and m2eclipse!
As a Java/Eclipse noob coming from a Visual Studio .NET background, I'm trying to understand how to set up my run/debug environment in the Eclipse IDE so I can start stepping through code.
I have built my application with separate src and bin hierarchies for each library project, and each project has its own jar. For example, in a Windows environment, I have something like:
c:\myapp\myapp_main\src\com\mycorp\myapp\main
...and a parallel "bin" tree like this:
c:\myapp\myapp_main\bin\com\mycorp\myapp\main
Other supporting projects are, similarly:
c:\myapp\myapp_util\src\com\mycorp\myapp\util
(and a parallel "bin" tree), etc.
So, I end up with, e.g., myapp_util.jar in the ...\myapp_util\bin... path and then add that as an external archive to my myapp_main project.
I also use utilities like gluegen-rt.jar, which I add ad external dependencies to the projects requiring them.
I have been able to run outside of the Eclipse environment, by copying all my project jars, gluegen-rt DLL, etc., into a "lib" subfolder of some directory and executing something like:
java -Djava.library.path=lib
-DfullScreen=false -cp lib/gluegen-rt.jar;lib/myapp_main.jar;lib/myapp_util.jar;
com.mycorp.myapp.Main
In the IDE, however, When I first pressed F11 to debug I got a message about something like /com/sun/../glugen... not being found by the class loader.
So, to debug, or even just run, in Ecplipse, I tried setting up my VM arguments in the Galileo Debug -> (Run/Debug) Configurations to be the command line above, beginning at "-Djava.libary.path...". I've put a lib subdirectory - just like the above with all jars and the native gluegen DLL - in various places, such as beneath the folder that my main jar is built in and as a subfolder of my Ecplipse starting workspace folder, but now the debugger can't find the main class:
java.lang.NoClassDefFoundError:
com.mycorp.myapp.Main
Although the Classpath says that it is using the "default classpath", whatever that is. Bottom line, how do I assemble the constituent files of a multi-project application so that I can run or debug in Eclipse?
if you want project A to have project B (and its libs) on its classpath, then goto project A's properties, select Java Build Path, then select the Projects tab. Here you Add project B.
Although you may be generating jars for each project, eclipse doesn't pay much attention to the jars. If you are going to have lots of java projects with lots of 3rd party dependencies, you may want to look at something like m2eclipse.
The recommended way of doing things is to configure the build path. This is a nice article describing the process.