ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Russell Stocum" <>
Subject Re: a few basic questions...
Date Wed, 11 Jul 2001 18:27:02 GMT
Humm now that brings up an interesting question.  I see what your saying...

See the source tree is built up of many projects as well as a common
package for reused classes.  So I would then adopt a hybrid of those ideas
if I was to follow that I have 1 build.xml for each project.  Since
projects are developed by different teams (sometimes at the same time).
But I would also need a build for the common as well as one to build the
whole package at the root.

So here is the issue.  At any point in time any of these classes might be
further developed by anyone, once it is released, for support reasons.  Am
I assuming too much to have to require them to edit the "projects"
build.xml file and use the knowledge that typing ANT in a subpackage of the
projects package (made for organizational purposes) would read that
projects build.xml file and compile their class...
Also the logic for compiling a class in a subpackage would need to be
different then the logic used in the main dir of the project.  When a new
comer is requested to add a class to the project they would need to specify
the path from the project trees root.

I thought it might be easier to have a simple rule that the build file in
the current directory compiles the classes in "that" directory.  And just
leave it at that... so that one has more freedom to change package
subpackages (subdirectories).  Since this is a corporate project its 80+
classes minimum and I can perhaps see one wanting to change the name of one
of the subpackages while the project is being developed...

The other though would be if one wanted to move classes from one level to
another, instead of having to retype lots of path names, you would just cut
and paste the <antcall> tag sections into the local build.xml...

Though I see merit in having one build file... But under the nature of the
compile environment... I don't know if it would actually make things more
complicated in the long run... humm, this will require more thought.
Thanks, I will have to hunt down that thread in the archives.


Don Taylor wrote:

> There's another thread that's been going on in this list that goes over
> the merits of having a "global" build where a single build.xml file
> builds everything versus a "local" build where each package has its own
> build.xml file and the whole thing is driven by a global build.xml
> which is essentially a director. It's a holistic vs. reductionistic
> argument.
> It really depends on why you have multiple packages in the first place.
> If they're just ways of organizing your project, then build everything
> in a global build.xml. If they're stand-alone packages that are put
> into jars that can or are being used for other projects then they
> should have their own build.xml and your project's build.xml should
> just ensure the package is up-to-date. That's how I like to approach
> builds.

View raw message