Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Message-ID: <A97C7354105F2B4C82C705D351F2BF470225BB5D@asc-msg-01>
From: thomas.cherel@ascentialsoftware.com
To: jeff@socialchange.net.au, ant-dev@jakarta.apache.org
Cc: thomas.cherel@ascentialsoftware.com
Subject: RE: XML include in build.xml files
Date: Mon, 26 Nov 2001 18:21:45 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C176D1.1D6ADE70"

------_=_NextPart_001_01C176D1.1D6ADE70
Content-Type: text/plain;
	charset="ISO-8859-1"

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

Thomas

-----Original Message-----
From: Jeff Turner [mailto:jeff@socialchange.net.au]
Sent: Monday, November 26, 2001 5:52 PM
To: Ant Developers List
Cc: thomas.cherel@ascentialsoftware.com
Subject: Re: XML include in build.xml files


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

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">
	]>

<project>
..
 &moreTargets;
..
</project>

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

(background for people not familiar with SGML Open Catalogs (socats):
http://www.arbortext.com/Think_Tank/XML_Resources/Issue_Three/issue_three.ht
ml)

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 Main.java 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;").


--Jeff

> 
> Thomas

------_=_NextPart_001_01C176D1.1D6ADE70--