ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shankar Unni <shan...@intruvert.com>
Subject Properties, scope and project hierarchies
Date Thu, 05 Jul 2001 22:17:37 GMT
> -----Original Message-----
> From: Kyle Adams [mailto:kadams@gfs.com]

> - add scoping rules for properties so that not all of them 
> will be inherited by sub-builds, only those that have been 
> specified explicitly. Fill in details once they've been sorted out. 

The key here is to consider what one wants out of a "project hierarchy". The
sorts of things that I have had to do in the past are (I'm going to talk in
"makefile" terminology, since that's what I've been using for C and C++
projects):

* Have one master file to build all other projects (trivial).
* Have a master set of properties and rules that can be shared by all the
build files. These need to be *PARAMETERIZED*.
* For single-valued properties: be able to define a default value in a
master file, and possibly override or undefine it in sub-builds.
* For path or list-valued properties: be able to define a default value, and
either override, or append or prepend to it in sub-builds. Typical examples
are classpaths, etc.

The desired end-result is to wrap all the complexity of the build mechanism
into one or more master buildfiles, so that invididual projects that are
built in essentially the same way can just have a small buildfile that just
defines or overrides a few things, and defers the rest of the compexity to
the master file.

(In the Make model I used, the end-project Makefiles were usually just a
couple of defines of mandatory things like the path to the source root, the
project and target names, and the list of sources, and everything else was
computed on the fly and/or reasonably defaulted from this information. Ant
should really be making it even easier, since it does much of this sort of
thing itself anyway...)

For instance, with Ant, I might define a default classpath (for common
libraries) in the master file, but individual build.xml's may wish to
prepend to that classpath for additional projects that they may need in the
classpath.

Or I might wish to add a few files to the fileset used for the default jar
rule. I.e. in addition to ${build}/**/*.class, I might wish to add an
explicit manifest file, or images, or whatever, on a per-buildfile basis.

I've been working over the documentation for a couple of days now, and can't
see convenient ways to do any of this.

Am I missing something here?
--
Shankar Unni.

Mime
View raw message