ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craeg K Strong <>
Subject [PATCH] Support for external catalog files in <xmlcatalog>
Date Fri, 10 May 2002 06:48:36 GMT

Enclosed please find the patches and new files for <xmlcatalog>
in order to support external OASIS catalog files via integration
with Norman Walsh's resolver library from Apache xml-commons.
(see: )

<xmlcatalog id="allcatalogs">
       publicId = "-//ArielPartners//DTD XML Article V1.0//EN"
       location = "com/arielpartners/knowledgebase/dtd/article.dtd"/>
   <catalogfiles dir="/my/catalogs" includes="**/catalog.xml"/>

There are quite a few files involved, because I am including documentation,
tests, and buildfile changes.  If there is a filter that prevents this
binary (zip) file attachment from getting through, please let me know
and I will resubmit the files as individual (ascii) attachments.

What I have implemented is 100% backwards compatible.  Further,

UNLESS the resolver.jar from xml-commons is available on the
classpath, there are no visible changes.  That is, Norman Walsh's resolver is 
used if it is found, otherwise <xmlcatalog> behaves exactly as it
did before.  I repeat, resolver.jar is _NOT_ required.

In this way, the 90% of people whose needs are satisfied using the
simple embedded <dtd> and <entity> elements can go on using them
and never bother with resolver.jar, while the 10% of people who need
more sophisticated entity/URI resolution can add resolver.jar and
presto! the additional functionality is supported.

I have extensively documented the new (and original :-) <xmlcatalog>
functionality, and the code is thoroughly commented.

For all of these reasons, the Ant committers may want to vote as to
whether to include this in the next beta of 1.5, rather than adding it
to 1.6alpha.  Either way, I will be happy to fix or add whatever you
guys feel is needed.

The submission is complete and I have tested it on Red Hat Linux and
Windows 2000.  I am still thinking, however, about creating some additional
test classes for the case when resolver.jar is present, without duplicating
the tests in xml-commons.  Suggestions, of course, are welcomed.



View raw message