ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David McTavish <>
Subject RE: Scaling to large projects
Date Mon, 03 Feb 2003 21:35:25 GMT
I try to follow this approach as well, but sometimes we get issues when we
depend on other software products (ie: we use jboss and tomcat, and they
don't synchronize their use of log4j, jdom, etc). So, we will end up with
some projects that are using different versions of the same libraries. For
the most part, everything works ok, but we do on occassion have to over-ride
this behaviour by having a separate lib folder for each project. I just
create symlinks for 99% of the jars to manage these, and the 1% of
inconsistencies have their symlink over-written. Of course this only works
if you are using a revisioning system that supports symbolic links.

What I was referring in my original email is when you have a project that
relies on code you have developed in another project. (ie: maven depends on
ant). You could either:
a) have a static binary from project A in the lib folder of project B
b) dynamically compile and build the library in project A as part of the
build process of project B.

There are inherent problems with the second approach in that it forces the
development stream of project B to always validate their code against a
moving target. 


-----Original Message-----
From: Steve Loughran []
Sent: Monday, February 03, 2003 4:28 PM
To: Ant Users List
Subject: Re: Scaling to large projects

----- Original Message -----
From: "David McTavish" <>
To: "'Ant Users List'" <>
Sent: Monday, February 03, 2003 11:03
Subject: RE: Scaling to large projects

> The only tricky part was when projects depended on other projects. I've
> refactored this to basically two lines per dependency in each build
> One to add the library to the compile classpath, and another inside the
> dependency of the compile target which imports the libraries to the local
> lib folder. I've refactored this such that it only requires two variables,
> the path to the dependent project, and the name of the archive to copy to
> the local lib folder. This means that you have to manually manage the
> dependencies between projects, which is more of a philosophical difference

the way I work is

-a central repository of libraries for every app. this makes it easier to
roll out updates across all apps


-a central properties.xml file to declare log4j.home, log4j.jar properties
set to the various locatons
-the file also to declare the dirs that various projects stick their output
-this file is included as an XML entity (see ant in anger for details)

So an app sets up a classpath of ${log4.jar},${axis.jar},${castor.jar},
${myapp.jar}, pulling them in from wherever they are defined; if one machine
wants to bind axis.jar to daily builds, that can be one in a properties file
loaded in properties.xml; the apps own build files are untouched.

Does this work? Yes, especially the bigger and more complex the project.
Having all the libs in one place makes maintenance easier.

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

View raw message