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 Sun, 23 Mar 2003 02:25:53 GMT
At 09:46 AM 3/22/03 -0800, you wrote:

>----- Original Message -----
>From: "Ray Tayek" <rtayek@attbi.com>
>To: <user@ant.apache.org>
>Sent: Saturday, March 22, 2003 00:10
>Subject: local build file with ant
>
>
> > hi, i''ve been trying to come up with a build file that lives in the
> > package that it builds (imho, this seems like the appropriate place for it
> > to hang out - but this is contrary to most of the examples i have seen).
>
>That's where you differ from everyone else. The reason to keep the build
>file at the base of a project is that you should only need one per project,
>and you end up with >1 package in any complex project. Many ant projects get
>away with a single build file. it keeps maintenance costs down and execution
>speed up.

having one build file at the base for a project that has a few (or 
more)  packages seems perfectly reasonable. and when the number of packages 
is more than a few, i suspect that you may wish to include them as jars or 
that there is information about how to build these jars, or just to compile 
one package or test that package. this information seems like it belongs as 
close as possible to what it is associated with. maybe thus could be done 
with property files or some fragment of a build file or something else? so 
the idea of having special knowledge in a top level build file that 
pertains to something more than a few levels down the source tree (or in 
another source tree) - say you need this version of some jar for that 
package and another version for some other package or some other scewball 
thing seems like a bad thing.

> > ... so i came up with the following build script (see below). this seems to
> > sorta do what i want (and it works in netbeans except for getting the
> > environment variables).
>
>You could try setting the basedir attribute of <project> as "../../.." and
>have everything resolved relative to there.

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.


> >
> > it seems like you would want to have one of these in most packages that 
> were deliverable ...
> > ...
> > i am wondering how to build on something like this when the build script is
> > at a higher level and wants to build all of the stuff below it. perhaps
> > there is some ant mechanism that goes around and builds everything below
> > it?. i would not object to having a build file in *every* package as that
> > will keep the information on how to build close to what it is building/
>
>That is the makefile approach; I guess you used make a lot, eh?

only a little, but i have seen one resursive makes and did not grok it. but 
i don't know how viable the idea is. seems like it might be.

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

>  but you dont need to . Javac happily
>compiles a directory tree, <jar> happily jars it. What more do you need.

for many small and medium cases, that will be sufficient.

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

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.

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