[Hibernate-JIRA] Commented: (HBX-709) Start distributing an eclipse Hibernate Tools runtime only JAR
8:20 p.m.
[
http://opensource.atlassian.com/projects/hibernate/browse/HBX-709?page=co...
]
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
7152
days inactive
7152
days old
hibernate-issues@lists.jboss.org
0 comments
1 participants
participants (1)
-
Darryl Miles (JIRA)