ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
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
http://nagoya.apache.org so that we can put that on our to-do list for Ant
1.5?

Thanks,
    Erik


----- Original Message -----
From: "Nascif Abousalh-Neto" <nascif@nortelnetworks.com>
To: <ant-user@jakarta.apache.org>
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
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 (
>
>


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