ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject RE: classpath
Date Wed, 06 Aug 2003 17:12:32 GMT

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}"/>

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...


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


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 
>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" ...
>-----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:
>   <fileset dir="${resources.lib.dir}">
>     <include name="*.jar"/>
>   </fileset>
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

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

View raw message