ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Weintraub" <>
Subject Re: Storing all libs in SCM?
Date Mon, 02 Jun 2008 20:37:41 GMT
The standard is to put your JAR files in a single directory like
$PROJ_DIR/lib or $PROJ_DIR/extern. Some people will divide up their
jars into various directories that might be needed for special types
of builds. For example: extern/lib for all standard libraries,
extern/server for JARs that are needed for the server, and
extern/client for all JARS that are needed for the client.

You can then use the javac task to specify your CLASSPATH for
compilation. You can do something like this:

<property name="common.classpath.dir" value="${basedir}/extern/lib"/>
<property name="server.classpath.dir" value=${basedir}/extern/server"/>
<property name="client.classpath.dir" value="${basedir}/extern/client"/>

<!-- Client Build -->
        <fileset dir="${common.classpath.dir}"/>
        <fileset dir="${client.classpath.dir}">
             <include name="*.jar"/>

The advantage is that your JAR files will automatically be included in
your classpath as you add JAR files into the correct extern
directories. And, since the JARS are versioned with the SCM system,
you checkout the correct version of the JAR files whenever you
checkout your project for development. In most SCM systems, the
directory is somewhat versioned with the files, so that if you add a
new JAR to REL_1.2 that was not in REL_1.0, you will see the new JAR
when you checkout REL_1.2, but not REL_1.0.

The disadvantage is that you cannot select the ordering of the JAR
files. If two JARS contain the same classname, the class that is used
is the one that is in the first JAR file in the classpath. Officially,
you don't know the exact classpath, so you can't specify which JAR
file should be first. To me, this is an extremely minor issue. You
shouldn't have two distinct JARs which contain duplicate class names.

By the way, I highly recommend you rename your JAR files to include
the revision in the name. For example, if you're using ftp.jar, rename
it to the correct version like ftp.2.3.jar or ftp.1.2.jar. This may
mean deleting the old JAR from the source archive (using "svn delete
ftp.1.2.jar" or
"cvs delete -f ftp.1.2.jar") and adding a new version back in (using
"svn add ftp.2.3.jar" or "cvs add ftp.2.3.jar").

This is a bit more work than just updating the JAR and committing the
latest version. But, this will help you know the exact revisions of
each third party JAR in your build. Developers can easily see what
defects are in a particular JAR. What that JAR supports, and what
could happen if they want to upgrade that JAR file.

Since JAR files are binary, you don't really gain anything by simply
updating the JAR file with the latest revision. You can't do a diff
between two binary revisions, and you don't save any room in your
source archive because binary files aren't saved in delta format.

On Mon, Jun 2, 2008 at 3:45 PM, Tim Visher <> wrote:
> Hello Everyone,
> I've been working on setting up an automated build environment using
> Ant for a few days while I try to move towards the Continuous
> Integration benchmark and I've run into a major snag that I can't seem
> to get past.  I've been doing a lot of reading about Agile Processes
> and Continuous Integration and one of the major things that keeps
> getting brought up is that you should have every component needed to
> build your software stored centrally via SCM in order to ensure that
> you are always able to reproduce any build.  I'm probably going to
> stop short of throwing the OS and DB software in there, but I would
> like to store all necessary lib jars (such as javaee.jar and mail.jar)
> in there so that when a vanilla box checks out the software, it has a
> constant place to look for all necessary library components.  So far,
> I've gotten things to work by putting the necessary lib files in
> ANT_HOME/lib and by using the -lib flag to specify an alternate
> location that also has the necessary lib files, but I can't figure out
> how to pass something like the -lib option internally to the build.xml
> file.  I've tried specifying the classpath property in the javac task
> but that did not work either, even though when I ran ant in -verbose
> mode the classpath option that was apparently being passed to javac
> did have the correct folder on it.
> I'm not sure where the break down in my understanding is but hopefully
> the above is more than enough info for someone to help me.  If it's
> not, please just ask as I've wasted too much time trouncing through
> the documentation.
> Thanks in advance for your help!
> --
> In Christ,
> Timmy V.
> - Spend less time on e-mail
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

David Weintraub

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

View raw message