ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Visher" <>
Subject Re: Storing all libs in SCM?
Date Tue, 03 Jun 2008 17:32:25 GMT
Also, terribly sorry for this incredibly n00b question, but I'm
wondering what you would set the ubiquitous ${basedir} property to,
since you want it to be cross platform.  Would that be some sort of
relative path?  In my build script currently I have basedir (in the
project tag) set to '.'.  This is great, but if I want to store the
external libs outside of all of the projects they support, I can't
even really imagine a good way to do that...  Thoughts there?  Thanks

On Mon, Jun 2, 2008 at 4:37 PM, David Weintraub <> wrote:
> 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 -->
> <javac
>    srcdir="${src.dir}"
>    destdir="${dest.dir}"
>    <classpath>
>        <fileset dir="${common.classpath.dir}"/>
>        <fileset dir="${client.classpath.dir}">
>             <include name="*.jar"/>
>        </fileset>
>    </classpath>
> </java>
> 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:


In Christ,

Timmy V. - Spend less time on e-mail

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

View raw message