[ xframe-Bugs-1165772 ] xsddoc maven plugin fails with Java 1.5

"SourceForge.net" <[email protected]> Fri, 22 Apr 2005 08:11:35 -0700
Newsgroups gmane.text.xml.xframe.xsddoc
Message-ID <[email protected]>
Bugs item #1165772, was opened at 2005-03-18 06:53
Message generated for change (Settings changed) made by kriede
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=454391&aid=1165772&group_id=48863

Category: maven
Group: xsddoc-0.7-beta
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Peter Runge (prunge)
Assigned to: Kurt Riede (kriede)
Summary: xsddoc maven plugin fails with Java 1.5

Initial Comment:
Attempting to run the xsddoc maven plugin with JDK 
1.5.0_02, using Maven 1.02.  The plugin runs, but results in 
the generated report indicating the xsddoc run failed.  
Clicking the log links on the report page indicate the 
following stack trace:

xsddoc failed with exception: Provider 
org.apache.xalan.processor.TransformerFactoryImpl not 
found
javax.xml.transform.TransformerFactoryConfigurationError: 
Provider 
org.apache.xalan.processor.TransformerFactoryImpl not 
found
	at 
javax.xml.transform.TransformerFactory.newInstance
(Unknown Source)
	at 
net.sf.xframe.xsddoc.Processor.initTransformers
(Processor.java:537)
	at net.sf.xframe.xsddoc.Processor.execute
(Processor.java:450)
	at net.sf.xframe.xsddoc.Processor.run
(Processor.java:475)
...

This seems to not just be a problem with the plugin as 
indicated by the following Maven bug:
http://jira.codehaus.org/browse/MAVEN-156

Since xalan is indeed a dependency of the xsddoc plugin, it 
is possibly a class loading issue with Maven.

A workaround would be to allow a project property to be set 
to override the default transformer.  In the maven-xsddoc-
plugin:report goal in plugin.jelly, the 
systemScope.setProperty line could be changed to read 
from a plugin property, which defaults to the current value.  
This would allow Java 1.5 people (or people who want to 
use other transformers) to use the xsddoc Maven plugin.


----------------------------------------------------------------------

Comment By: Kurt Riede (kriede)
Date: 2005-04-05 00:15

Message:
Logged In: YES 
user_id=484961

Damn. Again classloaders make life harder in Maven, but 
that's the way to handle different versions of Xalan in different 
plug-ins. anyway I will think about a solution for the next 
release. Thanx for your invenstigation effort. I guess your 
second approach will be my choice.

Since you seem to have good knowledge of Maven interals, 
may I ask if you have an idea regarding Bug-Report [1168954] 
Maven multiproject: no entry generated in Project Reports?
https://sourceforge.net/tracker/index.php?
func=detail&aid=1168954&group_id=48863&atid=454391

Regards
Kurt

----------------------------------------------------------------------

Comment By: Peter Runge (prunge)
Date: 2005-03-21 01:00

Message:
Logged In: YES 
user_id=416534

I've tried tinkering with the source to override the transformer to 
use the one that comes with JDK 1.5 
(com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryI
mpl) however this introduced other problems.  So my suggestion 
mentioned before about allowing the user to override the xalan 
transformer would be a bad idea.

Playing around a bit more, I found two solutions:

In the net.sf.xframe.xsddoc.Processor class, the initTransformers
() method can be changed.  Instead of using 
TransformerFactory.newInstance(), create the Xalan transformer 
factory directly by invoking the constructor.
tFactory = new 
org.apache.xalan.processor.TransformerFactoryImpl();  

A second solution would be to set the context class loader of the 
thread before invoking TransformerFactory.newInstance() in the 
initTransformers() method.  
Thread.currentThread().setContextClassLoader(getClass
().getClassLoader());

Both methods were tested with both JDK 1.5 and JDK 1.4 and 
seem to work.

The underlying issue is that the Java 
TransformerFactory.newInstance() method uses the context 
classloader to find the factory to use using the System 
property 'javax.xml.transform.TransformerFactory'.  Unfortunately 
Maven does not set the context class loader of the thread to the 
plugin's classloader before invoking plugins, so the 
TransformerFactory.newInstance() method would not ever search 
a plugin dependency's classes.  So either directly instantiating 
the factory class directly (which uses the plugin's class 
classloader) or setting the context class loader to the classloader 
of the plugin class will fix the problem.


----------------------------------------------------------------------

Comment By: Peter Runge (prunge)
Date: 2005-03-20 23:35

Message:
Logged In: YES 
user_id=416534

Hi Kurt,

using JDK 1.5:
After running the xsddoc:generate goal on my project, the output 
of maven does not indicate an error, it creates the 
target/docs/xsddocs directory and generates some files.  
The .xsd directories are created but are empty.  The txt files 
contain a bit of header text and then the stack trace.

using JDK 1.4 with the maven plugin works perfectly.

I also tried running the xsddoc batch file from the bin directory 
not using Maven at all.  This worked perfectly with JDK 1.5.


----------------------------------------------------------------------

Comment By: Kurt Riede (kriede)
Date: 2005-03-20 18:53

Message:
Logged In: YES 
user_id=484961

Hi Peter,
might you please briefly summarize your expirience with JDK 
1.5? Did you encounter any differences or problems? What 
about XalanJ? Anything special to do different than with JDK 
1.4?

Regards
Kurt

----------------------------------------------------------------------

Comment By: Peter Runge (prunge)
Date: 2005-03-18 07:05

Message:
Logged In: YES 
user_id=416534

(using plugin version 0.7)

Sorry, should have read '[ 1123251 ] maven plugin can't find 
xalan' before submitting this bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=454391&aid=1165772&group_id=48863


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click