[hibernate-issues] [Hibernate-JIRA] Commented: (HBX-709) Start distributing an eclipse Hibernate Tools runtime only JAR

[Darryl Miles (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-709?page=comments#action_24517 ] 

Darryl Miles commented on HBX-709:
----------------------------------

If you are not going to point them to an update site, simple dont configure a value.  But certainly don't configure a value to a location which you know is not an update site.  No user is going to manually open this file to read the URL in there to get it and depending upon which version of Eclipse you have, having a bogus update site configured can cause the update process to bomb out early (throw exceptions).  I have another plugin I use which is pointed to a site throwing a HTTP 404 and causes Update Manager not to allow me to get to the package selection page.

There is already the <description url="http://tools.hibernate.org"> which is user clickable URL, this can be accessed from the proprties information about the feature/plugin.

Ideally if you have multiple update sites then based on what you are stating you would have:

Nighties: Omit the <url> elements completely
Development Branch: Point to http://download.jboss.org/jbosside/updates/development/
Stable Branch: Point to http://download.jboss.org/jbosside/updates/stable/


As I say I tried a wide variety of configuration and update options to confirm the original features.xml was exactly and after further experimentation some of the import referenced were turned from plugin reference to feature references.

The point that was being made before was that some features like org.eclipse.wst.common_core.feature, you are already referencing (and redistributing) all the imports of their constituent plugins anyway, so yes it would make things simpler.

I think I understand the point you are maintaining.  Since you don't redistribute the features/ files yet; then you can't reference them, sorry I was ahead of myself and already of the mindset you are redistributing the features/ files (as per Plan A listed at the top of this bug report).


But the main problem has been delt with by change over to using imports, now Hibernate Tools is happy to accept and activate a newer version of a plugin instead of insisting on binding to a specific version and accepting no other.


> 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira