[
http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=co...
]
Brill Pappin commented on HBX-706:
----------------------------------
This issue still exists using hibernate 3.2.2.ga
Hibernate ant task does not work in a multi-project Maven 2 build if
other mojos use javax.xml.transform
--------------------------------------------------------------------------------------------------------
Key: HBX-706
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HBX-706
Project: Hibernate Tools
Type: Bug
Components: ant
Versions: 3.1beta4
Environment: Hibernate 3.1, database is Oracle (but not relevant to this)
Reporter: Alfie Kirkpatrick
Fix For: 3.2beta7
Attachments: hibernate-problem.zip
I have a reasonably complex maven 2 build with multiple projects. More than one of the
projects uses the hbm2java task and at least one of the projects uses the Codehaus
xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works
fine. But running the master build throws the following error.
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
[snip]
Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version
at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223)
[snip]
I can't really explain where this error is coming from. I looked at the source for
putInContext and it is using the Plexus options class and failing because the value of
"version" is already in the options.
I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using
some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform
and the problem remained.
I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP
implementation (Xalan?).
.. and it worked fine!
So this is definitely a problem with the instantiation of the default XSLT functionality
in JDK1.4, although how that can possibly affect the build in this way is beyond me.
You might consider this a Maven bug but it's very strange that it doesn't happen
for any old mojo combination. I also think it is probably much easier to fix in Hibernate
tools than in Maven.
I'd suggest a couple of possible fixes/improvements:
- Make "version" key more specific, eg. hibernate.tools.version to avoid
possible clash with other Plexus clients in the same JVM
- Don't throw an exception on any existing value being set as it is now but compare
the value in the options to the new value and only throw an exception if they differ
I can't think of a way to track down the underlying cause of this issue. It's a
very odd one.
Attached is a simple three project build to reproduce the problem. Just run 'mvn
clean package' on the parent project to reproduce.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira