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:[EMAIL PROTECTED] Sent: Monday, November 26, 2001 5:52 PM To: Ant Developers List Cc: [EMAIL PROTECTED] Subject: Re: XML include in build.xml files On Mon, Nov 26, 2001 at 01:01:05PM -0500, [EMAIL PROTECTED] 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
