ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dIon Gillard <d...@multitask.com.au>
Subject Re: Using catalogs to resolve external entities?
Date Sat, 16 Feb 2002 15:29:47 GMT
I started coding this a week ago.

I'm currently at the point of having coded the xcatalog datatype as a 
first level datatype for ant.

What I'm  slow in doing at the moment, is working out how to set the 
datatype as an entity resolver for the style task (or others...)

Feel like helping??

Nascif Abousalh-Neto wrote:

>Hi,
>	I'm porting a large project, with hundreds of makefiles, from GNU
>make to Ant. Today our makefiles include most of their functionality from
>"template" files, which is great for maintenance. I'm trying to implement
>the same functionality in Ant, and it seems that only two ways are currently
>available:
>	1) Delegating the common functionality to a "common" build.xml file,
>using the Ant task.
>	Pros:
>	 - you can set the location of the common build.xml file using
>properties
> 	 - it is a self-contained file, so it is easier to validate (test)
>	Cons:
>	- not trivial to customize. You can pass properties but can't pass a
>reference to a classpath.
>	- Ant parses the whole referenced file for each delegated command.
>
>	2) Using external XML entities
>	Pros
>	- the file is parsed only once, at XML parse time
>	- supports properties and references
>	Cons
>	- you have to import XML fragments
>	-  you have to specify the path to the include file as a relative
>reference to the current build.xml location.
>
>So I decided to use number 2, but having to hardcode relative paths really
>sucks, specially for large project trees with many levels of indirection. I
>took a look at Crimson, the XML parser used by Ant, and it does have an API
>for catalogs. It would be great if Ant could be extended to use it, because
>it would eliminate the issue of the hardcoded relative paths. For example,
>instead of:
>
><!DOCTYPE project [
>    <!ENTITY common  SYSTEM "file:./../../../../common.xml">
>]>
>
>We would be able to use:
>
><!ENTITY common
>         PUBLIC "-//mycompany//loadbuild-common-code//EN"
>         "common.xml">
>
>The PUBLIC name could be used to obtain the URI from a catalog provided to
>Ant at launch time - no need to specify a relative location.
>Ant would just have to expose the Crimson APIs that allow the user to
>register mappings for public names (i.e. the XML catalog); for example,
>passing a file in the command line or specifying it in an environment
>varianle (ANT_CATALOG?).
>
>This is the method I'm talking about, from class
>org.apache.crimson.parser.Resolver:
>
>    /**
>     * Registers the given public ID as corresponding to a particular 
>     * URI, typically a local copy.  This URI will be used in preference
>     * to ones provided as system IDs in XML entity declarations.  This
>     * mechanism would most typically be used for Document Type Definitions
>     * (DTDs), where the public IDs are formally managed and versioned.
>     *
>     * @param publicId The managed public ID being mapped
>     * @param uri The URI of the preferred copy of that entity
>     */
>    public void registerCatalogEntry (
>	
>


-- 
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers




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


Mime
View raw message