ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: local build file with ant
Date Sun, 23 Mar 2003 10:55:30 GMT
On Saturday, March 22, 2003, at 09:25  PM, Ray Tayek wrote:
> i will try that. but i don't want the entire source tree to be 
> compiled. and i have no clue about what to do with multiple source 
> trees.
> i have your book (thanks - it;s been very helpful), and another called 
> java tools for xp, where the author does something with nested build 
> files, but i am not sure i fully grok that and his approach may only 
> work for a source tree that is layed out like his, so that may not be 
> applicable in some random large source tree.

Have a look at my JavaDevWithAnt project:

it has multiple source trees (src/common, src/ejb, src/anttask, and 
src/web) - each of these has separate builds, essentially, in the one 
and only top-level build.xml file.  There are some dependencies, of 
course, such that src/common is built prior to src/ejb.

>> You can do it in ant with <ant>,
> great! - now all i have to do is figure out how :(
> would you have any pointers to example of this? iirc, you allude to 
> this in your anger article.

The above example project does  not even use <ant>.  It does use 
<antcall> internally to keep the <javac> in one place, though.

> for projects that require more than a few packages, there are some 
> design principles about the unit of release and reuse. i would think 
> that you would want to have build files that make and test these 
> packages before you compile and run tests on whatever code you are 
> working on and then deliver it (these packages may need to be 
> customized somehow). the alternative is to have another project for 
> each of these packages, which either begs the question (mine) or 
> require more projects that live outside their packages (imho, a bad 
> thing again).

Have a look at how JavaDevWithAnt deals with 3rd party dependencies, 
such as Struts and Lucene.  This might give you some insight into how 
to deal with your own "packages".  I think this word is being 
overloaded in this conversation to mean distributables or JAR files 
though, so let's be careful since packages refers to Java packages to 
most of us.

> my ideas are all based on the principle that the information about 
> something (a package) should hang out near that thing (cohesion?). 
> just trying to get my poor brain straightened out on this somehow.

Again, careful about "packages" here.  If your JAR files are truly 
reusable across multiple "projects", then I would recommend having 
separate projects and separate build.xml files for them, yes, but not 
quite in the same directory structure you seem to be after here.  And 
projects that needed those dependent JAR files would not build the 
sub-JAR's, per se, but rather rely on them being there (where is 
"there"?   Well, a master build would control that, or a default 
repository directory would be used).


View raw message