ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Using catalogs to resolve external entities?
Date Fri, 15 Feb 2002 21:03:55 GMT
This seems like a very reasonable and useful enhancement to Ant.  Would you
mind please filing this as an enhancement request at so that we can put that on our to-do list for Ant


----- Original Message -----
From: "Nascif Abousalh-Neto" <>
To: <>
Sent: Friday, February 15, 2002 1:25 PM
Subject: Using catalogs to resolve external entities?

> 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
> 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.
> took a look at Crimson, the XML parser used by Ant, and it does have an
> for catalogs. It would be great if Ant could be extended to use it,
> 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
>      * (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 (

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message