ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: XML include in build.xml files
Date Mon, 26 Nov 2001 23:21:45 GMT
Agree with all your comments.
As I said in a previous reply, for the moment my catalog is a very simple
Java property file. I did that only to validate the idea. Seems that those
catalogs are not going to be as simple as what I thought, but I still think
it is worth trying.

Agree that the relative path might be a way to solve the problem, but in our
current development environment, I am just afraid of having too much build
files with relative paths, so if the reusable xml documents are changing
places (and I am sure they will over time), it might be a little bit painful
to update all the relative paths. But may be it will be even more painful to
implement a catalog feature.

I read a couple of things on what is supposed to be done for Ant2, and I did
not get a chance yet to look at the corresponding W#C spec to understand if
they address the kind or problem I have or not. Unless Ant will allow the
XInclude to be parameterized with ant properties, in which case it will
solve my problem completely (almost, I am not sure I can wait for Ant2 :-)


-----Original Message-----
From: Jeff Turner []
Sent: Monday, November 26, 2001 5:52 PM
To: Ant Developers List
Subject: Re: XML include in build.xml files

On Mon, Nov 26, 2001 at 01:01:05PM -0500, 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.

Just to clarify.. I take it you mean the &entity; method of pulling in
additional XML?

<!DOCTYPE project [
    <!ENTITY moreTargets SYSTEM "file:build-xtra.xml">


> Using a catalog to map public identifier to system identifier will
> centralize this information.

(background for people not familiar with SGML Open Catalogs (socats):

So you want to have a PUBLIC id instead of SYSTEM, and then use a
catalog to look up the real SYSTEM id?

I'm curious as to why you'd need anything more complicated than a
relative reference, as shown above? Ie, why not just ensure your SYSTEM
id is relative, and correct?

> The modifications that I did are the following:
> 	- add -catalog option to to specify a catalog file (public
> to system identifier mapping)

That implies you're using a set of classes to parse the catalog file,
right? But...

> 	- add a Hashtable member variable mapping public to system
> identifier to the project class (so it can be passed
> on to sub-projects)

.. this implies you're using a fixed lookup table?

> 	- 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?

A decent inclusion mechanism would certainly be nice, and I think has
been accepted for Ant 2. I'm not sure that most people need a
centralized catalog of 'build components', which I gather is what you've
created. It's a nice feature though. I suspect what gets implemented for
Ant 2 will be more like XInclude (eg <ant:include file="foo.xml"/>) than
XML entities ("&foo;").


> Thomas

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