[Hibernate-JIRA] Closed: (HBX-709) Start distributing an eclipse Hibernate Tools runtime only JAR
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-709?page=all ]
Max Rydahl Andersen closed HBX-709:
-----------------------------------
Fix Version: 3.2beta8
Resolution: Fixed
this is being done by the jbosside build system.
i've done the part needed in the hibernate tools so its possible to do it.
> Start distributing an eclipse Hibernate Tools runtime only JAR
> --------------------------------------------------------------
>
> Key: HBX-709
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-709
> Project: Hibernate Tools
> Type: Task
> Reporter: Darryl Miles
> Fix For: 3.2beta8
> Attachments: feature.xml
>
>
> http://forum.hibernate.org/viewtopic.php?t=962374
> Start to pickup and use Eclipse/WTP versioning within the features.xml/
> Plan of action as I see it:
> * Copy features/org.eclipse.* and features.org.apache.* files as well as pre-requisite plugins/* when packaging.
> * Move <plugin ...> into <import ...> in features/org.hibernate.eclipse.feature_3.2.0.beta6a/feature.xml (see attached sample of this working for me)
> * Modify build and packaging process to now create two JARs.
> JAR one contains (this is the runtime only JAR):
> features/org.hibernate.eclipse.feature*
> plugins/org.hibernate.eclipse*
> plugins/org.jboss.ide.eclipse.freemarker*
> JAR two contains (this is the equivalent of what is distrubuted now, hibernate tools, with WTP/XSD/GEF/JEM pre-requisites, without Eclipse Platform)
> All the files in JAR one above, plus
> plugins/org.eclipse.gef*
> plugins/org.eclipse.wst.xml_core.feature.*
> plugins/org.eclipse.wst.common_core.feature*
> plugins/org.eclipse.wst.common_ui.feature*
> plugins/org.apache.xerces.feature*
> plugins/org.eclipse.xsd*
> plugins/org.eclipse.jem*
> plugins/org.eclipse.wst.xml_ui.feature*
> plugins/org.eclipse.emf*
> features/org.eclipse.gef*
> features/org.eclipse.wst.xml_core.feature_*
> features/org.eclipse.wst.common_core.feature_*
> features/org.eclipse.wst.common_ui.feature_*
> features/org.apache.xerces.feature_*
> features/org.eclipse.xsd_*
> features/org.eclipse.jem_*
> features/org.eclipse.wst.xml_ui.feature_*
> features/org.eclipse.emf_*
> By removing the <plugin ..> declarations from the hibernate JAR it stops the JAR claiming it is the authorative source for that plugin to the update manager. By including the original features/ files from the original authorative source means that if a user installs pre-requisites (or has pre-requisites already installed) when they use JAR two, and restart Eclipse will automatically pickup and use the lastest installed version of WTP/XSD/EMF/GEF/JEM compatible with hibernate tools.
> This has the effect is automatically upgrading the version of pre-requisites when multiple versions are found. But in the event the users version of pre-requisites is too old or non-existant then the ones in the JAR two will be picked up and used.
> If the re-packaged version of freemarker is also being used inside other JBOSS plugins, then I would suggest a seperate feature/org.jboss.ide.eclipse.freemarker*/feature.xml be provided and all plugins built on top are then to pickup that with an <import ...> declaration. If hibernate tools is the only user of freemarker then leading it inside hibernate tools is fine.
--
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
18 years, 3 months
[Hibernate-JIRA] Closed: (HBX-706) Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=all ]
Max Rydahl Andersen closed HBX-706:
-----------------------------------
Fix Version: 3.2beta7
Resolution: Fixed
assume fixed since no further reporting.
would though be interesting to hear if maven has challenges in using e.g. hibernate 3.1.3 for runtime and hibernate3.2 for the codegen parts ?
> 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
18 years, 3 months