Title: Properties, scope and project hierarchies

> -----Original Message-----
> From: Kyle Adams [mailto:[EMAIL PROTECTED]]

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

Reply via email to