ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: Ant <project> extension, templatized build files
Date Fri, 03 May 2002 12:32:04 GMT
I have been using a similar approch myself:

o I have a project descriptor for every top-level project which lists the
individual subprojects, dependencies between subprojects and on other
top-level projects.  The dependencies are compile time dependencies, meaning
that if project a depends on b, b has to be built first and place the
resulting class files in a known location.
o There is a buildfile template for both top-level and subproject buildfiles
(essentially all the same).
o With an XSLT stylesheet I generate buildfiles for the top-level project
and one for every subproject.

So the difference to Peter's approach is basically that the template and
XSLT stylesheet have been separated.  The stylesheet simply copies the
template and replace certain tags in it.

The goal of this setup is to achieve:
o uniformity across the buildfiles
o means to externalize inter-project dependencies from buildfiles
o automatic generation of buildfiles

This seems to work quite nicely, but there are some things demanding for
o The inter-project dependencies are also reflected in the individual
buildfiles in the form of <ant> calls.  I think it would be nice if these
could be removed.
o While it is possible to customize the generated buildfile, the changes
will be lost once the buildfiles have to be regenerated (due to changed
dependencies or altered template).  It would be nice to have some kind of
inheritance and overriding or pre- and post-target mechanism like Chad
proposed.  But using <ant> calls is both cryptic and slow as Peter points

Maybe extending the syntax of <target> to support dependencies on targets in
other buildfiles (projects) would be a good way to go.  This would be some
kind of merge of the current <target> implementation and <ant> task.  But of
course I'd lose some expressive power which <ant> provides.

I still can't think of a nice way to support separation of a template
buildfile and a customization of it which would either override or extend
targets in the template.


> -----Original Message-----
> From: Peter Donald []
> Sent: Freitag, 3. Mai 2002 13:25
> To: Ant Developers List
> Subject: Re: Ant <project> extension, templatized build files
> Hi,
> On Thu, 2 May 2002 13:55, Chad Loder wrote:
> > I describe my solution below -- I'd like to know what people
> > think of it. Peter, in particular, I think you and I may be 
> trying to
> > solve different problems (my needs being somewhat simpler).
> >
> > I'd like to get comments on this proposed solution (improvements?
> > possible complications or limitations down the road for large
> > projects?).
> It is an interesting approach. Problems may arise in the 
> future when you end 
> up with larger numbers of subprojects (ie I currently work 
> with about 30 in 
> avalon excalibur and about 6 in ant-myrmidon) which may have other 
> differences that need to be "injected" at different stages at 
> the build.
> The other problem is that you use lots of ant/antcalls which 
> are very very 
> slow (they require reparsing configuring and building project 
> each time) and 
> can consume lots of memory. Some of these problems are worsed 
> by certain 
> IDEs/editors (the IDEA editor can take 30% longer if lots of 
> ant calls - not 
> sure why).
> What I would suggest is that you use XSLT to generate your 
> build files if you 
> really need the templating (alternatively just do copy paste 
> between build 
> files). For an example of XSLT in action download the 
> jakarta-ant-myrmidon 
> CVS. The following are the files to look at
> jakarta-ant-myrmidon/build.xml
> jakarta-ant-myrmidon/tools/xsl/build.xsl
> jakarta-ant-myrmidon/*/project.xml
> The first file acts as the "driver" script and generates all 
> required build 
> scripts and then delegates to them. The second is the xsl 
> sheet used to 
> transform the project descriptors into real build files. The project 
> descriptors just contain unique data for each project.
> Anyways I like it as a user but Adam/Darrell wrote it so they 
> may have some 
> comments on how hard/easy it was to write.
> -- 
> Cheers,
> Peter Donald
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message