ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: XML include in build.xml files
Date Mon, 26 Nov 2001 22:39:07 GMT
On Tue, 27 Nov 2001 05:01, wrote:
> I am kind-of new to the Ant world but I already start to like it. I am
> currently experimenting with ant1.4.1 to
> replace our current build environment (MKSToolkit + gmake).
> I end up looking at ant source code, and started to modify it to push my
> experiments.
> I will send multiple emails on the modifications that I did since they are
> not all related to each other.
> This first modification is related to the inclusion of xml documents into
> build.xml files using public
> identifier instead of only system identifier. It seems that being able to
> create reusable pieces of build.xml files is
> very useful. Only problem with that, the path of those reusable xml chunks
> needs to be hardcoded in each build.xml files.
> Using a catalog to map public identifier to system identifier will
> centralize this information. The modifications that
> I did are the following:
> 	- add -catalog option to to specify a catalog file (public
> to system identifier mapping)
> 	- add a Hashtable member variable mapping public to system
> identifier to the project class (so it can be passed
> on to sub-projects)
> 	- modify resolveEntity in ProjectHelper to check with Project object
> if a public to system identifier mapping
> is available (when public id is not null).
> Do you agree that such feature is useful?

Very much so!!!

I would love to see this code. However there is a few questions that need to 
be answered first. Mainly about where you got the catalog code from. Is it 
Norman Walshes early PD code ? Is it his later work under Suns very nasty 
license? Or is it a custom job?

If you answered no to the second question then send it along. If you answered 
yes to the second question then we have a problem. Cocoon (from is actually faced with a similar problem at this stage and 
there are people pushing for it to to return to being PD code or at least 
more freely licensed. So you may want to drop them a line if you are using 
suns resolver.jar

> I did not find any other ways to share class path definitions, target or
> task commons to multiple build.xml, and things
> like that. Loading properties from a file is working well but only for
> properties, 


> and calling targets in another
> build.xml will work only if the targets are 100% parameterized and even
> like that, basedir and other top level properties
> will be changed because of a different build.xml, and I think it will be a
> problem at some point).

There is also the problem that in some things they will never be supported ;)



Kitsch never goes out of style

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message