ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nascif Abousalh-Neto"<nas...@nortelnetworks.com>
Subject Using catalogs to resolve external entities?
Date Fri, 15 Feb 2002 18:25:12 GMT
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 (
	

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message