ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Tayek <rta...@attbi.com>
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: 
>http://www.ehatchersolutions.com/JavaDevWithAnt

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 http://tayek.com/ actively seeking mentoring or telecommuting work
vice chair orange county java users group http://www.ocjug.org/
hate spam? http://samspade.org/ssw/


Mime
View raw message