From: Alfie K. (JIRA) <no...@at...> - 2006-07-14 14:51:57
|
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 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Max R. A. (JIRA) <no...@at...> - 2006-07-14 15:02:58
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23634 ] Max Rydahl Andersen commented on HBX-706: ----------------------------------------- please try and use a more uptodate version and tell me if the problem persists. (because i don't understand why all those things should affect the tools) > 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 > 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Alfie K. (JIRA) <no...@at...> - 2006-07-14 15:28:58
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23635 ] Alfie Kirkpatrick commented on HBX-706: --------------------------------------- Thanks for the quick reply... I changed to the following dependencies (the latest on public maven repos): <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate</artifactId> <version>3.2.0.cr2</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-tools</artifactId> <version>3.2.0.beta6</version> <scope>compile</scope> </dependency> I now get a: java.lang.NoClassDefFoundError: org/hibernate/engine/query/sql/NativeSQLQueryReturn at java.lang.Class.getDeclaredMethods0(Native Method) Thanks, Alfie. > 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 > 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Max R. A. (JIRA) <no...@at...> - 2006-07-14 15:36:56
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23636 ] Max Rydahl Andersen commented on HBX-706: ----------------------------------------- you need to use the latest hibernate (or at least the hibernate that comes with the tools). Could we take this discussion to the forums until we actually figure out that a bug exists ? :) thank you. > 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 > 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Alfie K. (JIRA) <no...@at...> - 2006-07-14 16:05:59
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23637 ] Alfie Kirkpatrick commented on HBX-706: --------------------------------------- I suspect this issue has gone away in newer builds. The hbm2java task certainly got further than before before it hit the noclassdef error. I'd like to help with more testing but I don't have time to get the latest tools, install in my maven repo with any new dependencies, etc, etc. I also have a slight worry that the latest tools beta runs against Hibernate 3.2 which is itself in beta so even if it does fix the bug we may be stuck with it on the current released version. And I have workarounds in place for it. I'll start in the forum next time. Apologies. Thanks! Alfie. > 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 > 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Max R. A. (JIRA) <no...@at...> - 2006-07-14 21:47:00
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23640 ] Max Rydahl Andersen commented on HBX-706: ----------------------------------------- you should just use the hibernate 3.2 builds with the codegen; not needed for running your apps. > 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 > 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |