ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabor Maghera" <>
Subject Re: Storing all libs in SCM?
Date Tue, 03 Jun 2008 21:19:24 GMT
As far as slashes go (and colon or semicolon for classpaths), use the
path syntax that you are comfortable with.  Ant will do the platform
specific translation for you.  But I'd stick with relative paths, as
Ant will not translate something like C: from Windows into / on UNIX.


On Tue, Jun 3, 2008 at 10:32 AM, Tim Visher <> wrote:
> 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
> again!
> 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:

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

View raw message