ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: classpath
Date Thu, 07 Aug 2003 09:30:15 GMT
I wanted to minimise configuration changes needed to my build.xml files 
in these situations, so the approach I took is to use this to compile 
the classpath:

<path id="compile.classpath">
   <!-- include external jars specified in project -->
   <filelist files="${external.jars}"/>

which the javac task uses. I specify ${external.jars} in my project's like this:


This comma-delimited file list picks up its properties from another which I load first, which is local to the machine and 
looks like this:


With this set-up it means I only have to modify my 2 
files - and other programmers only have to modify their local file, as long as you check in project 
into CVS or source-safe or whatever.

I had to modify the source code for taskdefs/ and 
types/ to make this work, since beforehand, FileList would 
not play ball with a list of files from different windows drives since 
it required a from-directory. I would like to persuade the Ant 
committers that these changes are worthy of inclusion in the Ant src, 
but I'm not sure how to go about it. It seems it is an art form to get 
committers interested - any suggestions? The changes are not huge.


Jacob Kjome wrote:
> It seems to me the build file should have some idea of which libraries 
> are required for building the application in question.  I use a system 
> that I adapted from the Tomcat5 build.  I set up a path to hold 
> libraries for use in a classpath like this...
>     <path id="build.classpath" >
>         <pathelement location="${skaringa.jar}"/>
>         <pathelement location="${log4j.jar}"/>
>         <pathelement location="${commons-jxpath.jar}"/>
>         <pathelement location="${ant-contrib.jar}"/>
>     </path>
> I specify versions of these libraries in a file.  And 
> since I don't actually store any of these libraries locally or 
> distribute them with the build, I have a dynamic downloading process 
> that first checks if they are available locally and then downloads them 
> if they don't yet exist.  Once it is downloaded and stored on disk, it 
> doesn't need to be downloaded again unless the libraries are deleted or 
> a new version is specified.  This is actually very similar to how Maven 
> works where it loads libraries that don't exist locally from 
> (actually anyone can use this resource if they want).  When I update a 
> version number, the old version is no longer added to the classpath and 
> the new version is downloaded and used.
> A sampling of a build that uses this technique can be seen in the 
> current Prevayler build...
> build.xml


> utility-targets.incl (an include file that contains reusable Ant targets 
> that some targets in build.xml use)

> Jake
> At 10:11 AM 8/6/2003 -0600, you wrote:
>> To help get around the "library version" problem, we will rename the 
>> library jar files with a version number if they don't come with one. 
>> (e.g. junit.jar becomes junit_3-8-1.jar.) We can then tell at a glance 
>> which version of the library it is.
>> To help get around the "conflict" problem (we had a project where the 
>> library directory had servlet.jar and j2ee.jar, both containing the 
>> javax.servlet.* hierarchy) we now point to the directory of our 
>> servlet container (Tomcat) to get the jar files provided by the 
>> container. We still have to worry about particular libraries 
>> containing the same classes, but since we have a small number of Java 
>> developers and we don't use different libraries that do similar things 
>> it usually isn't a big problem.
>> You might consider having a library czar. A single person who approves 
>> all library dependencies. I would suggest that this person is also the 
>> build and deploy person.
>> -- Nathan Christiansen
>>    Tahitian Noni International
>> -----Original Message-----
>> From: Keith Hatton []
>> Sent: Wednesday, August 06, 2003 9:50 AM
>> To: Ant Users List
>> Subject: RE: classpath
>> Really it's a tradeoff between control and ease of use.
>> We use pretty much the same technique as Nathan, and it works for the 
>> time being.
>> But, over time, I can see the potential for our "lib" directory to 
>> fill up, and you lose control of which versions of what libraries are 
>> included, and if there is any conflict (same classes in 2 jars) you 
>> have to guess which one will be used ... so you may decide the 
>> approach of specifying each jar is better, and live with the 
>> maintenance requirement that comes with it.
>> Oh dear, it sounds like another case of "no silver bullet" ...
>> Keith
>> -----Original Message-----
>> From: Nathan Christiansen []
>> Sent: 06 August 2003 16:43
>> To: Ant Users List
>> We have used the following code, and it picks up all jar files in a 
>> directory:
>> <classpath>
>>   <fileset dir="${resources.lib.dir}">
>>     <include name="*.jar"/>
>>   </fileset>
>> </classpath>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message