ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Tayek <>
Subject Re: local build file with ant
Date Fri, 28 Mar 2003 11:04:32 GMT
At 05:55 AM 3/23/03 -0500, you wrote:
>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. ...
>>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: 

will do.

>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.

ok, i'll check them out.

>>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 ...
>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.

yes, we should be careful. but i don't care how small the "package" is, i 
just want to keep info about it in it.

>>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",

yes, they would tend to be (especially the smaller ones) and they will have 
unit and other tests attached.

>then I would recommend having separate projects and separate build.xml 
>files for them, yes,

it would seem that the build file for those separate projects should also 
be where their source lives in the tree.

>  but not quite in the same directory structure you seem to be after here.

now for some monster app where you had to deliver som combinations of 
prohects, i can see a separate build file outside the source tree 
(probabl;y no source for this guy anyway).

>   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).

ok, this has been enlightening.

thanks for your assistance.

ray tayek actively seeking mentoring or telecommuting work
vice chair orange county java users group
hate spam?

View raw message