Thank you Stefan, that was very helpful, and informative regarding the path
loading issues.
I'm now definitely making some progress.
I've passed in ${resolverpath} via "-lib" and have ${catalogpath} in my
<xmlcatalog>.
Where ${resolverpath} is the full path, including ".jar", and ${catmanpath} is
the full path to Catalog.xml.
where previously I got :
"Apache resolver library not found, internal resolver will be used
Warning: XML resolver not found; external catalogs will be ignored
Failed to load Apache resolver: java.lang.NoClassDefFoundError:
org/apache/xml/resolver/tools/CatalogResolver
No matching catalog entry found, parser will use: 'profile-mode.xsl'"
I now get :
"Class org.apache.tools.ant.types.resolver.ApacheCatalogResolver loaded from
parent loader (parentFirst)
Ignoring Exception java.util.zip.ZipException: error in opening zip file
reading resource META-INF/services/javax.xml.parsers.SAXParserFactory from
C:\Projects\Tools_RK\DocBook-System\CatalogManager\Catalog.xml
Couldn't load ResourceStream for
META-INF/services/javax.xml.parsers.SAXParserFactory
Class com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl loaded from
parent loader (parentFirst)
Apache resolver library found, xml-commons resolver will be used
Using catalogpath
'C:\Projects\Tools_RK\DocBook-System\CatalogManager\Catalog.xml'
Parsing C:\Projects\Tools_RK\DocBook-System\CatalogManager\Catalog.xml
Class
com.sun.org.apache.xerces.internal.parsers.XIncludeAwareParserConfiguration
loaded from parent loader (parentFirst)
Class com.sun.org.apache.xerces.internal.impl.dv.dtd.DTDDVFactoryImpl loaded
from parent loader (parentFirst)
Ignoring Exception java.util.zip.ZipException: error in opening zip file
reading resource META-INF/services/javax.xml.parsers.SAXParserFactory from
C:\Projects\Tools_RK\DocBook-System\CatalogManager\Catalog.xml"
Which at least now indicates it's being found.
However it is not always getting the files I want, so something is still not
right.
There are two <xslt> tasks in my ant file, the first is working correctly, ie
imported files are being found at locations corresponding to what the catalog
says (though as I can't set verbosity I can't check the logic for this).
Is the business about "error in opening zip file" worth noting ? I don't think
I need a zip file, do I ? (I know .jar files are zip format - do I need
another jar somewhere to make this work ?)
"Yes, you directly point to the catalog itself."
I've done that, as above. However ...
"I don't think the properties file is required at all. "
But, the properties file contains a control for verbosity, which can be useful
in diagnosing problems within it.
Is there another way of controlling that ?
Despite now having evidence that the resolver is being used I am still finding
the problem in that the imported style file I'm using isn't being found.
However the second <xslt> task is not successfully finding its imports via the
catalog.
I see the following in the log :
"[xslt] Loading stylesheet
C:\Projects\Tools_RK\DocBook-System\WebHelp\CustomWebHelp.xsl"
This is as expected.
But later I get :
"resolve: 'webhelp/xsl/webhelp.xsl' with base:
'file:/C:/Projects/Tools_RK/DocBook-System/WebHelp/CustomWebHelp.xsl'
Class org.apache.tools.ant.types.resolver.ApacheCatalogResolver loaded from
parent loader (parentFirst)
Ignoring Exception java.util.zip.ZipException: error in opening zip file
reading resource META-INF/services/javax.xml.parsers.SAXParserFactory from
C:\Projects\Tools_RK\DocBook-System\CatalogManager\Catalog.xml
Couldn't load ResourceStream for
META-INF/services/javax.xml.parsers.SAXParserFactory
Class com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl loaded from
parent loader (parentFirst)
Apache resolver library found, xml-commons resolver will be used
Ignoring Exception java.util.zip.ZipException: error in opening zip file
reading resource META-INF/services/javax.xml.parsers.SAXParserFactory from
C:\Projects\Tools_RK\DocBook-System\CatalogManager\Catalog.xml
Couldn't load ResourceStream for
META-INF/services/javax.xml.parsers.SAXParserFactory
Class com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl loaded from
parent loader (parentFirst)
Class
com.sun.org.apache.xerces.internal.parsers.XIncludeAwareParserConfiguration
loaded from parent loader (parentFirst)
Class com.sun.org.apache.xerces.internal.impl.dv.dtd.DTDDVFactoryImpl loaded
from parent loader (parentFirst)
[xslt] : Error!
C:\Projects\Tools_RK\DocBook-System\WebHelp\webhelp\xsl\webhelp.xsl (The system
cannot find the path specified)"
There is an xsl:import of 'webhelp/xsl/webhelp.xsl' in CustomWebHelp.xsl, so
the first line of this block makes some sense.
However, there is no
C:\Projects\Tools_RK\DocBook-System\WebHelp\webhelp\xsl\webhelp.xsl, so
although that Error line is correct I don't know why it's trying as there is a
'webhelp/xsl/webhelp.xsl' entry within Catalog.xml.
Thank you again for your help so far.
I hope we can get this sorted as I think I am very nearly sorted now.
Appreciatively,
Richard.
Richard Kerry
BNCS Engineer, SI SOL Telco & Media Vertical Practice
T: +44 (0)20 82259063[X]<thismessage:/Body.htm#>
M: +44 (0)7812 325518[X]<thismessage:/Body.htm#>
G300, Stadium House, Wood Lane, London, W12 7TA
richard.ke...@atos.net<https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=mailto%3arichard.kerry%40atos.net>
This e-mail and the documents attached are confidential and intended solely for
the addressee; it may also be privileged. If you receive this e-mail in error,
please notify the sender immediately and destroy it. As its integrity cannot be
secured on the Internet, the Atos group liability cannot be triggered for the
message content. Although the sender endeavours to maintain a computer
virus-free network, the sender does not warrant that this transmission is
virus-free and will not be liable for any damages resulting from any virus
transmitte
________________________________
From: Stefan Bodewig [bode...@apache.org]
Sent: 14 September 2013 05:48
To: user@ant.apache.org
Subject: Re: Use of XML Catalog with Ant (xslt task) - request for example
On 2013-09-13, Kerry, Richard wrote:
> "ant-resolver.jar and xml-resolver.jar "
> hang on a moment ............. what are these ?
> I thought I just needed resolver.jar from xml-commons-resolver-1.2
> (assuming that's the latest), so what are these two ?
xml-resolver.jar is the one from xml-commons, it comes under different
names, sorry for the confusion.
ant-resolver.jar is part of the Ant distribution and contains the
binding between Ant and the xml-commons resolver.
> And (previous response) I don't touch ant-apache-resolver.jar, which
> is already under ant/lib, as it's an internal library
Then resolver.jar from xml-commons must be there as well or things won't
work because of classloader delegation.
> What is not clear to me is which one of these files needs to be
> specified in the <xmlcatalog> element. Given that the properties file
> specifies the (relative) location of the catalog file itself I assume
> that's the one I need to specify. Can someone please confirm this, or
> explain otherwise ?
I don't think the properties file is required at all. Yes, you directly
point to the catalog itself.
> I am seeing the following messages :
> "Apache resolver library not found, internal resolver will be used
> Failed to load Apache resolver: java.lang.NoClassDefFoundError:
> org/apache/xml/resolver/tools/CatalogResolver"
> Which looks like it's saying I haven't got the resolver loaded.
Right, see above. The manual about xmlcatalog also has this innocent
note "but they will be ignored unless the resolver library from
xml-commons is available in the *system classpath*" (emphasis by me).
The resolver.jar from xml-commons must be either on CLASSPATH or inside
$ANT_HOME/lib or ~/.ant/lib or specified via -lib
Java builds a hierarchy of classloaders and the way Ant uses them
classes loaded high up in the hierarchy cannot see classes loaded
further down. At the root there is CLASSPATH and nested <classpath>
elements are loaded via a loader further down the hierarchy.
Ant's binding to xml-resolver (the ant-resolver.jar) is loaded high up
in the hierarchy - at least higher than any <classpath> element - and so
the resolver.jar from xml-commons must be located at least as high
inside the hierarchy for Ant to find it.
In essence this is a case very similar to
<http://ant.apache.org/faq#delegating-classloader> if you ignore the
first sentence of the answer which is specific to <junit>.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
