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 14:16:40 GMT
Thanks David.

Clearly my misunderstanding was in the use of the classpath tag.  I
tried to use that but was unable to get it work.  I'll try sometime

Do I understand that you're not a fan of dependency management from
the likes of Ivy or Maven then?  Gilles recommended that I look into
Ivy and I hadn't yet so I went and did that this morning and it looks
pretty intriguing.  One thing I noticed right off the bat was that it
did not have javaee.jar (at least not that I could find) available.
However, it did have junit.jar.  The 4 dependencies that I have at the
moment which are not in the jdk are javaee.jar, mail.jar,
derbyclient.jar, and junit.jar.  I think there's a breakdown somewhere
in my understanding about how to make the 'standard' jars available to
ant.  What started me down this whole path was that I could not use
any of the JEE classes in the System.  Right now I have no CLASSPATH
variable but I can still use all of the standard JDK libs, javac just
seems to know about them.  Is there a way to do this with the JEE
classes as well?

Beyond that, the other question I would have about dependency
management (with something like Ivy vs. Manually) is how you would go
about SCMing that.  It seems like a 'dangerous' thing to allow an
outside entity to manage all of your dependencies for you.  You're not
guaranteed that a particular jar will always be there, you need an
internet connection to get to it (at least at first), etc. etc.  Is
there something I'm missing there?  Or is that the major downfall of
using a dependency management tool?

Thanks so much for your help!

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