Maven 1

classpath or jelly:xml issue with XSLT transformations

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0-beta-7
  • Fix Version/s: 1.1-beta-1
  • Component/s: jelly/ant integration
  • Labels:
    None
  • Environment:
    win2k, 1.4.1-b21, maven b7 and also winxp, jdk 1.3.1-01, maven b6
  • Number of attachments :
    0

Description

see also my mail to the user list titled 'Style task / x:transform problem'

It seems there is a general problem with XSLT launched from maven. My own transforms in the maven.xml and that in the docbook plugin behave the same. Behaviour is that instead of transforming as expected the transform command is printed to console. Some processing has occurred (eg var substitution). For example the following:

<style in="project.xml"
out="${meta.dir}/orion-application.xml"
style="${code.templates.dir}/orion-application.xsl"/>

prints this to the console:

<style in="project.xml" out="META-INF/orion-application.xml" style="c:/projects/jdf3/utils/templates/codegen/orion-application.xsl"></style>

but no transform.

The same thing results when using x:transform. Other jelly:xml commands such as x:parse and so on work fine

Using a <java> command to fork a VM and launch a Xalan Process command, taking control of the classpath works ok so I am using this a workaround.

Hopefully it will be obvious to someone that better understands the way maven loads its classes!

Issue Links

This issue is duplicated by:
MAVEN-1601 XSLT transformations fail with JDK 1.5 Major Closed
This issue is depended upon by:
MEVENIDE-147 Unable to compile with Maven 1.0.2 and JDK 1.5 Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
dion gillard added a comment -

see how this is done in the latka plugin

Show
dion gillard added a comment - see how this is done in the latka plugin
Hide
Permalink
Brett Porter added a comment -

this definitely works for me when using the JAXP properties with the ant style task. I'll add a wiki entry.

This can be closed?

Show
Brett Porter added a comment - this definitely works for me when using the JAXP properties with the ant style task. I'll add a wiki entry. This can be closed?
Hide
Permalink
dion gillard added a comment -

Where's the wiki link?

If it's ok, I'll take it and add it to the FAQ.

Show
dion gillard added a comment - Where's the wiki link? If it's ok, I'll take it and add it to the FAQ.
Hide
Permalink
Brett Porter added a comment -

FAQ 4.9 in case this link doesn't work:
http://wiki.codehaus.org/maven/FrequentlyAskedQuestions#head-6ffef73e17a0455edf38ab9569fb38cda23642be

Show
Brett Porter added a comment - FAQ 4.9 in case this link doesn't work: http://wiki.codehaus.org/maven/FrequentlyAskedQuestions#head-6ffef73e17a0455edf38ab9569fb38cda23642be
Hide
Permalink
dion gillard added a comment -

I'd rather leave this open until a solution can be found that doesn't involve the hack.

Show
dion gillard added a comment - I'd rather leave this open until a solution can be found that doesn't involve the hack.
Hide
Permalink
Brett Porter added a comment -

Didn't realise it was considered a hack - fair enough though.
Is it related to the classloader isolation at all?

Show
Brett Porter added a comment - Didn't realise it was considered a hack - fair enough though. Is it related to the classloader isolation at all?
Hide
Permalink
Juha Komulainen added a comment -

The above solution does not work on JDK 5.0 at all, where JDK does not include Xalan, but uses XSLTC.

The problem is that when JDK's TransformerFactory tries to load the defined transformer "org.apache.xalan.processor.TransformerFactoryImpl", it doesn't see the classes in Maven's own classloaders, even if plugin has defined Xalan as a dependency.

Fortunately TransformerFactory will try to use Thread's context-classloader instead of system classloader if one is defined. Would it be possible for Maven to set the context classloader to the classloader of the plugin whenever invoking the plugin?

Show
Juha Komulainen added a comment - The above solution does not work on JDK 5.0 at all, where JDK does not include Xalan, but uses XSLTC. The problem is that when JDK's TransformerFactory tries to load the defined transformer "org.apache.xalan.processor.TransformerFactoryImpl", it doesn't see the classes in Maven's own classloaders, even if plugin has defined Xalan as a dependency. Fortunately TransformerFactory will try to use Thread's context-classloader instead of system classloader if one is defined. Would it be possible for Maven to set the context classloader to the classloader of the plugin whenever invoking the plugin?
Hide
Permalink
Sergey Tereschenko added a comment -

Solution from FAQ 4.9. "How do I get the XSLT tasks to work?" really don`t work under JDK 5.0.
I hack this bug in maven xml with string:
${systemScope.setProperty('javax.xml.transform.TransformerFactory','com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl')}
when call my ant task.
But i dont want use xalan transformer. I need to use saxon.

Its very ugly bug.

Show
Sergey Tereschenko added a comment - Solution from FAQ 4.9. "How do I get the XSLT tasks to work?" really don`t work under JDK 5.0. I hack this bug in maven xml with string: ${systemScope.setProperty('javax.xml.transform.TransformerFactory','com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl')} when call my ant task. But i dont want use xalan transformer. I need to use saxon. Its very ugly bug.
Hide
Permalink
Peter Runge added a comment -

This is also a problem when transforms are done in unit tests on JDK 1.5. The workaround suggested above works, but what if the unit tests need to be run on 1.4?

Show
Peter Runge added a comment - This is also a problem when transforms are done in unit tests on JDK 1.5. The workaround suggested above works, but what if the unit tests need to be run on 1.4?
Hide
Permalink
Brett Porter added a comment -

now depending on JDK 1.4, and this works (not to mention makes Maven a lot slimmer)

Show
Brett Porter added a comment - now depending on JDK 1.4, and this works (not to mention makes Maven a lot slimmer)

People

Vote (5)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.