ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.che...@ascentialsoftware.com
Subject RE: XML include in build.xml files
Date Mon, 26 Nov 2001 23:04:14 GMT
For my current implementation the catalog is just a Java property file (I
was just trying to validate the idea).
Definitely not enough to support a minimal catalog.
I started looking at XML spec without finding anything on the syntax of such
catalog and I am 100% open to suggestions.
I am not familiar with Norman Walshes work. I know that we might be able to
find something in James Clark code (SP) even if not written in Java. This is
the only piece of code that I saw which is able to handle catalogs.

What did you mean by your last sentence: "There is also the problem that in
some things they will never be supported"? Are you saying that there might
some support problems in the future for calling targets in another build.xml
file?

Thanks for the feedback.

Thomas


-----Original Message-----
From: Peter Donald [mailto:peter@apache.org]
Sent: Monday, November 26, 2001 5:39 PM
To: Ant Developers List
Subject: Re: XML include in build.xml files


On Tue, 27 Nov 2001 05:01, thomas.cherel@ascentialsoftware.com 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 Main.java 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 
xml.apache.org) 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, 

yep.

> 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
;)

-- 
Cheers,

Pete

------------------------------
Kitsch never goes out of style
------------------------------

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>

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