Bug 47704 - Allow Project to take an XMLCatalog instance for use in configuring catalog-aware tasks
Summary: Allow Project to take an XMLCatalog instance for use in configuring catalog-a...
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-18 21:19 UTC by Eliot Kimber
Modified: 2009-08-21 05:51 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eliot Kimber 2009-08-18 21:19:34 UTC
When running Ant from within for example a CMS system exposed as a Web app, there are several problems with managing resolution of XML resources (entity resolution, URI resolution):

- It is not possible to have different classpaths for different uses of Ant (for example, different DITA Open Toolkit instances accessible through main CMS application)

- Setting a classpath on XMLCatalog in the build file or task (e.g., within <xslt>) appears to have no effect, even when resolver.jar is on the classpath (but in any case, just using CatalogManager with static catalog files is not sufficient.

- There is no way to initialize Project with a pre-existing URI resolver, for example, one that does CMS-specific resolving of CMS-specific URLs.

Enhancement request:

Allow Project to have an XMLCatalog instance set on it and use this catalog to initialize e.g., XSLTProcess.

In examining the 1.7.1 source I could find any place that setConfiguredCatalog() is ever called on XSLTProcess. I think this may be a code bug but I haven't had a chance to verify that.
Comment 1 Stefan Bodewig 2009-08-21 05:51:33 UTC
addConfiguredXMLCatalog is invoked by Ant's reflection when it encounters an xslt task with a nested <xmlcatalog> element.