On Tue, 13 Mar 2001, Pierre Delisle wrote:
> Anything to simplify the 'build' files each taglib has to maintain is good.
>
> A question for an ant guru. Are there any thoughts given in ant so that the
> same principle could be applied to build.xml?
>
> Let me explain. As you mention, there will be a lot of duplication in the
> build.xml in each taglib. Just like there is
>
> <property file="../build.properties">
>
> it would be great if there was something like:
>
> <build file="../build.xml">
>
> which would act as the "super-build" (as an analogy to superclass) of the
> current build.xml. By default, the "sub-build" targets would be used, unless
> they were overridden by the 'sub-build'.
>
> With something like this, what would need to be in each taglib "buil.xml"
> would be really minimal. Just a thought...
>
Isn't this what the <ant> task does? We use it in Tomcat to allow each
major component (catalina, jasper, tester, and webapps) to manage their
own build environment separately.
For taglibs, you might also want to look at an approach I recently
implemented in the Struts build process. There are now six webapps
created with Struts, and 95% of the build commands for each of them are
identical. So, I abstracted the steps required to build a single webapp
into a single build script (build-webapp.xml), and created a master build
that used this same script for each subordinate webapp. For example, the
master build's "compile" target includes commands like this:
<target name="compile">
<ant antfile="build-webapp.xml" target="compile">
<property name="webapp.name" value="webapp-1"/>
</ant>
<ant antfile="build-webapp.xml" target="compile">
<property name="webapp.name" value="webapp-2"/>
</ant>
... and so on ...
</target>
Because the structure of each tag library's directory is supposed to be
the same, you might be able to apply the same sort of approach here, and
create a single "build-taglib.xml" script that is used for all of
them -- and potentially have no individual build.xml scripts at all.
Craig McClanahan
