Right now there exists a workaround to the problem of property scope. Using the
Antcall task, you can override a property set in a "master" file, and pass that
property on to a sub-build file. I used that to pass a ${project.dir} variable that
described the relative location of the subproject (ie, com/gfs/common/project) - as
the variable gets passed down from a master build file to a child build file, the
master build file appends the child build file's directory onto the path.
For example:
c:\dev\src\ant -Dproject.dir = com/gfs/common
<ant dir="subproject" target="build">
<property name="project.dir" value="${project.dir}/subproject"/>
</ant>
This can be used to modify a path as it gets passed down a build hierarchy. The
antcall task can also be used to do the same thing with other targets in the same
build file.
Kyle
>>> [EMAIL PROTECTED] 07/05/01 06:17PM >>>
* 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.
