-
1. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
Just read over the thread and the comments in Hibernate JIRA...
To make a "runtime-only" bundle of Hibernate Tools (or any of JBossIDE's components) would be a relatively easy thing to do from the perspective of our build process. The only issue that comes to mind is the "further" confusing of multiple types of downloads... imagine now that we will have:
- Bundle downloads for win32+linux (eclipse+all components plugins/features+dependencies)
- ALL downloads (all components plugins/features+dependencies)
- 8-10 standalone component downloads (component plugins/features + dependencies)
- 8-10 "Runtime" downloads (component plugins/features ONLY)
So basically that pumps up the number of files to the low 20s. If we re-use our download matrix/guide methodology we can probably structure the page in such a way where it isn't as confusing, but for users who are just browsing our sourceforge page they would be SOL =).
Anyway, I'm not saying "no", I think we just need to discuss the best way of going about doing this. This discussion also prompts me to ask another question: Should we rethink the way we are distributing releases? Most eclipse plugins only package themselves as "runtime" plugins, and then maybe have a "Bundle" that includes dependencies, but no where near the level of granularity in component/dependencies that we do. Would users suffer to much if we threw that out the window? -
2. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
Unfortunately I don't have the answers to making it easy for a new user to get started (over and above an all-in-one archive).
The way I see the Eclipse architecture is that each feature should principally be distrubuted in isolatation first. "Runtime only" version that is the way nature intended.
You are already in no-mans-land when you start distributing anything between an all-in-one and runtime only and thats a hiding to nothing in the future with with permutations of platform and feature sets and to this I can't really offer anything.
There maybe suggestions that can be made to update manager development team on this, for example if after a platform restart (or -clean) a new feature/plugin is detected and it can not be activated (due to missing dependancies) then they get a prompt on screen offering was to resolve that problem by locating and downloading those missing dependancies.
The way I see the new user problem at the moment is that the platform does not help them enough when a pre-requisite problem occurs. When I think that issue should be in their face to deal with (or ignored) as soon as its detected, even little things like notification confirming a new plugin was detected and is activated giving the user positive feedback their unzip worked correctly. -
3. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
There are a couple of things here, first thing is that our feature.xml is apparently prohibiting people from using a later version of WTP ... we shouldn't (unless we know of a specific incompability, right ?)
The other is how we package our stuff and Marshall lists the worstcase scenario of the number of packages. But looking at http://download.jboss.com/jbosside/builds/nightly/200608012131-nightly/buildResults.html it isn't that bad is it ?
Can't this be "cleaned" up ?
e.g. instead of having core, jbossas and ejb3 tools as seperate plugins could they not be toghether ? When do you want them seperate ?
Drools, AOP, Hibernate Tools, Designer and FreeMarker are the only "true" independent ones.
And afaik Drools and FreeMarker are "true" independents in the word they don't need anything else but Eclipse leaving only AOP, Hibernate Tools and Designer as the only one that "needs" a "runtime-download" option. -
4. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
"max.andersen@jboss.com" wrote:
There are a couple of things here, first thing is that our feature.xml is apparently prohibiting people from using a later version of WTP ... we shouldn't (unless we know of a specific incompability, right ?)
I'm not sure its actually "prohibiting". Maybe it appears to work if you were to give it a try.
My objection is that two copies of some plugins end up installed that are different versions and because I am manually installing I really don't have any fallback of ensuring the install was correct.
My piece of mind comes from:
* Making sure no files are overwritten
* Making sure the plugin namespaces are kept apart -
5. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
>My piece of mind comes from:
>* Making sure no files are overwritten
When does this occur ? the update site shouldn't overwrite anything.
>* Making sure the plugin namespaces are kept apart
+1 -
6. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
"max.andersen@jboss.com" wrote:
When does this occur ? the update site shouldn't overwrite anything.
I am not using the update site. -
7. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
And even if you don't why does overwriting files matter ?
It should have zero effect assuming that WTP and Eclipse have gotten their version numbering under control now (which is the raw basis for even trying to make a pure runtime version) -
8. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
Because I don't want your re-distributed version of WTP (in any way shape or form) as I've already installed an official version. I'm expecting to install just the components hibernate is uniquely bringing into the world from hibernate.
-
9. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
so copy without overwriting and you got it like you want it ;)
-
10. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
No I consider it a "namespace collision" that hibernate is distributing org.eclipse.* stuff. I'm only allowing org.eclipse.* to come from the eclipse website. Depending upon which base version of WTP I use files may or may not be overwritten but conceptually there is still an unclean namespace collision by the fact your redistributing.
I was doing something like:
unzip "${BASEDIR}/HibernateTools-3.2.0.beta6a.zip" \
"features/org.hibernate.*" \
"plugins/org.hibernate.*" \
"plugins/org.jboss.*" || exit 1
To filter unwanted stuff out. If the plugin works afterwards great.
But I've had large periods of times over the past 6 months where the hibernate plugin has not been working (for whatever reason).
But the feature.xml inside hibernate tools is just all wrong IMHO. You should not be using <plugin ..> for any org.eclipse.* stuff. You should be using <import ...> and when you redistribute any org.eclipse.* stuff you should also be redistrubting the features/org.eclipse.* files too.
There is also <include ...> which I'm not sure what it means but I have seen it in other plugins. Maybe swapping <plugin ..> to <include ..> in the current hibernate tools feature.xml for all org.eclipse.* namespace components is a step in the right direction.
This request is back to my original hibernate tools query and the example features.xml in JIRA.
In looking into matters a little more I am finding other possible problems with the plugin versioning system (in general) which dont make sense to me yet. -
11. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
the reason we don't distribute the whole feature is that then it would really make no sense since it would be full complete download.
For hibernatetools that is approx. 80 megs more of useless stuff (from the perspective of using the hibernate tools) -
12. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
"max.andersen@jboss.com" wrote:
the reason we don't distribute the whole feature is that then it would really make no sense since it would be full complete download.
But you are distributing whole features.
You may not be distributing the whole feature "org.eclipse.wst_feature" but you are distributing the whole feature "plugins/org.eclipse.wst.common.core_feature". Correct me if I am wrong.
Here is a list of distinct features from my installation:./org.eclipse.wst_1.5.0.v200606092300-boSnpRZVq78N2Sm/feature.xml ./org.eclipse.wst.common_core.feature_1.5.0.v200606281000--AXrVWXWenBdN5D/feature.xml ./org.eclipse.wst.common_core.feature.source_1.5.0.v200606281000--AXrVWXWenBdN5D/feature.xml ./org.eclipse.wst.common_sdk.feature_1.5.0.v200605151622-842282744366203/feature.xml ./org.eclipse.wst.common_ui.feature_1.5.0.v200605221440-qKHiTHXXRmX527L/feature.xml ./org.eclipse.wst.common_ui.feature.source_1.5.0.v200605221440-qKHiTHXXRmX527L/feature.xml ./org.eclipse.wst.common_userdoc.feature_1.5.0.v200605151622/feature.xml ./org.eclipse.wst.doc.isv.feature_1.5.0.v200605151622--0842282932423A/feature.xml ./org.eclipse.wst.rdb_adapters.feature_1.5.0.v200605151622--Cq0bcpcmqDlaFE/feature.xml ./org.eclipse.wst.rdb_adapters.feature.source_1.5.0.v200605151622--Cq0bcpcmqDlaFE/feature.xml ./org.eclipse.wst.rdb_core.feature_1.5.0.v200605151622--3YIAAYAZFJDWMR/feature.xml ./org.eclipse.wst.rdb_core.feature.source_1.5.0.v200605151622--3YIAAYAZFJDWMR/feature.xml ./org.eclipse.wst.rdb_sdk.feature_1.5.0.v200605151622-PD88P8MBJAQCG-N/feature.xml ./org.eclipse.wst.rdb_ui.feature_1.5.0.v200605221715-FTMjwSqf2f9Nd6y/feature.xml ./org.eclipse.wst.rdb_ui.feature.source_1.5.0.v200605221715-FTMjwSqf2f9Nd6y/feature.xml ./org.eclipse.wst.rdb_userdoc.feature_1.5.0.v200605151622--4hNDDhDcFjDKTF/feature.xml ./org.eclipse.wst.sdk_1.5.0.v200606092300-F-KiXECYOy549ML/feature.xml ./org.eclipse.wst.server_core.feature_1.5.0.v20060707------1G955G5I8A/feature.xml ./org.eclipse.wst.server_core.feature.source_1.5.0.v20060707------1G955G5I8A/feature.xml ./org.eclipse.wst.server_sdk.feature_1.5.0.v200605221710-842282929-XOQMc/feature.xml ./org.eclipse.wst.server_ui.feature_1.5.0.v20060707-PGIEUH0RZEbHaHO/feature.xml ./org.eclipse.wst.server_ui.feature.source_1.5.0.v20060707-PGIEUH0RZEbHaHO/feature.xml ./org.eclipse.wst.server_userdoc.feature_1.5.0.v200605151622--08422827262353/feature.xml ./org.eclipse.wst.web_core.feature_1.5.0.v200605151622--3YIAAYAZFSEVUA/feature.xml ./org.eclipse.wst.web_core.feature.source_1.5.0.v200605151622--3YIAAYAZFSEVUA/feature.xml ./org.eclipse.wst.web_sdk.feature_1.5.0.v200605151622-84228282937520B/feature.xml ./org.eclipse.wst.web_ui.feature_1.5.0.v200606071530-ziPyPn2s-xsITzd/feature.xml ./org.eclipse.wst.web_ui.feature.source_1.5.0.v200606071530-ziPyPn2s-xsITzd/feature.xml ./org.eclipse.wst.web_userdoc.feature_1.5.0.v200605151622--1G955G5E7K7GDB/feature.xml ./org.eclipse.wst.ws_core.feature_1.5.0.v200606071530-4hNDDhDlJd2LXe8/feature.xml ./org.eclipse.wst.ws_core.feature.source_1.5.0.v200606071530-4hNDDhDlJd2LXe8/feature.xml ./org.eclipse.wst.ws_sdk.feature_1.5.0.v200605151622-842282744367202/feature.xml ./org.eclipse.wst.ws_ui.feature_1.5.0.v200605221450-pN9nBHUSQIhBl1V/feature.xml ./org.eclipse.wst.ws_ui.feature.source_1.5.0.v200605221450-pN9nBHUSQIhBl1V/feature.xml ./org.eclipse.wst.ws_userdoc.feature_1.5.0.v200605221940--1G955G5E777H7C/feature.xml ./org.eclipse.wst.xml_core.feature_1.5.0.v200605151622--3YIAAYAZFRDOMF/feature.xml ./org.eclipse.wst.xml_core.feature.source_1.5.0.v200605151622--3YIAAYAZFRDOMF/feature.xml ./org.eclipse.wst.xml_sdk.feature_1.5.0.v200605151622-842282744365_-9/feature.xml ./org.eclipse.wst.xml_ui.feature_1.5.0.v200605221438-7plFl1V9HDuVa-w/feature.xml ./org.eclipse.wst.xml_ui.feature.source_1.5.0.v200605221438-7plFl1V9HDuVa-w/feature.xml ./org.eclipse.wst.xml_userdoc.feature_1.5.0.v200605151622--3YIAAYAUCVDLMP/feature.xml
-
13. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
that stuff is definitly not needed in hibernate tools distribution....are you not looking at the full big distribution now ?
-
14. Re: WAS: Hibernate Tools not forward compatible with WTP (@h
"max.andersen@jboss.com" wrote:
that stuff is definitly not needed in hibernate tools distribution....are you not looking at the full big distribution now ?
LOL. No! I think you are missing the point being made.
Here is a listing of org.eclipse.* files from hibernate tools:59149 Fri Jul 14 03:07:30 BST 2006 plugins/org.apache.xerces_2.8.0.v200606131651/resolver.jar 1201551 Fri Jul 14 03:07:32 BST 2006 plugins/org.apache.xerces_2.8.0.v200606131651/xercesImpl.jar 198762 Fri Jul 14 03:07:30 BST 2006 plugins/org.apache.xerces_2.8.0.v200606131651/xml-apis.jar 484641 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.draw2d_3.2.0.v20060626.jar 154682 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.emf.common_2.2.0.v200606271057.jar 69767 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.emf.ecore.change_2.2.0.v200606271057.jar 73902 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.emf.ecore.edit_2.2.0.v200606271057.jar 169972 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.emf.ecore.xmi_2.2.0.v200606271057.jar 749588 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.emf.ecore_2.2.0.v200606271057.jar 225067 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.emf.edit_2.2.0.v200606271057.jar 748073 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.gef_3.2.0.v20060626.jar 91656 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.jem.util_1.2.0.v20060530_RC2.jar 35071 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.wst.common.core_1.1.0.v200606130645.jar 182926 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.wst.common.emf_1.1.0.v200606130645.jar 122035 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.wst.common.emfworkbench.integration_1.1.0.v200606130645.jar 37662 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.wst.common.environment_1.0.100.v200606130645.jar 106267 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.wst.common.frameworks_1.1.0.v200606130645.jar 162102 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.wst.common.project.facet.core_1.1.0.v200606130645.jar 172610 Fri Jul 14 03:07:32 BST 2006 plugins/org.eclipse.wst.common.project.facet.ui_1.1.0.v200606130645.jar 119099 Fri Jul 14 03:07:34 BST 2006 plugins/org.eclipse.wst.common.ui_1.1.0.v200606142122.jar 31779 Fri Jul 14 03:07:34 BST 2006 plugins/org.eclipse.wst.common.uriresolver_1.1.0.v200606130645.jar 388727 Fri Jul 14 03:07:34 BST 2006 plugins/org.eclipse.wst.dtd.core_1.1.0.v200606141450.jar 367107 Fri Jul 14 03:07:34 BST 2006 plugins/org.eclipse.wst.sse.core_1.1.0.v200606141450.jar 670902 Fri Jul 14 03:07:34 BST 2006 plugins/org.eclipse.wst.sse.ui_1.0.101.v200606191900.jar 184914 Fri Jul 14 03:07:34 BST 2006 plugins/org.eclipse.wst.validation_1.1.0.v200606130645.jar 603544 Fri Jul 14 03:07:34 BST 2006 plugins/org.eclipse.wst.xml.core_1.1.0.v200606142000.jar 646889 Fri Jul 14 03:07:34 BST 2006 plugins/org.eclipse.wst.xml.ui_1.0.100.v200606141450.jar 697947 Fri Jul 14 03:07:34 BST 2006 plugins/org.eclipse.xsd_2.2.0.v200606271057.jar
These files constiture the following FULL features from pre-requisites:<import plugin="org.eclipse.gef" version="3.2.0" match="greaterOrEqual"/> <!-- REF1 --> <import plugin="org.eclipse.wst.xml_core.feature" version="1.5.0" match="greaterOrEqual"/> <!-- REF2 --> <import plugin="org.eclipse.wst.common_core.feature" version="1.5.0" match="greaterOrEqual"/> <!-- REF3 --> <import plugin="org.eclipse.wst.common_ui.feature" version="1.5.0" match="greaterOrEqual"/> <!-- REF4 --> <import plugin="org.apache.xerces.feature" version="2.8.0" match="greaterOrEqual" /> <!-- REF5 --> <import plugin="org.eclipse.xsd" version="2.2.0" match="greaterOrEqual" /> <!-- REF6 --> <import plugin="org.eclipse.jem" version="1.2.0" match="greaterOrEqual" /> <!-- REF7 --> <import plugin="org.eclipse.wst.xml_ui.feature" version="1.5.0" match="greaterOrEqual" /> <!-- REF8 --> <import plugin="org.eclipse.emf" version="2.2.0" match="greaterOrEqual" /> <!-- REF9 -->
Except you dont also distribute the related feature files here is a list of SOME of the missing files from the HibernateTools distiribution:features/org.eclipse.emf_2.2.0.v200606271057 features/org.eclipse.emf_2.2.0.v200606271057/license.html features/org.eclipse.emf_2.2.0.v200606271057/eclipse_update_120.jpg features/org.eclipse.emf_2.2.0.v200606271057/feature.properties features/org.eclipse.emf_2.2.0.v200606271057/epl-v10.html features/org.eclipse.emf_2.2.0.v200606271057/feature.xml features/org.eclipse.gef_3.2.0.v20060626/ features/org.eclipse.gef_3.2.0.v20060626/license.html features/org.eclipse.gef_3.2.0.v20060626/eclipse_update_120.jpg features/org.eclipse.gef_3.2.0.v20060626/feature.properties features/org.eclipse.gef_3.2.0.v20060626/epl-v10.html features/org.eclipse.gef_3.2.0.v20060626/feature.xml features/org.eclipse.jem_1.2.0.v20060530_RC2--ZasJzJJez/ features/org.eclipse.jem_1.2.0.v20060530_RC2--ZasJzJJez/license.html features/org.eclipse.jem_1.2.0.v20060530_RC2--ZasJzJJez/eclipse_update_120.jpg features/org.eclipse.jem_1.2.0.v20060530_RC2--ZasJzJJez/feature.properties features/org.eclipse.jem_1.2.0.v20060530_RC2--ZasJzJJez/epl-v10.html features/org.eclipse.jem_1.2.0.v20060530_RC2--ZasJzJJez/feature.xml features/org.eclipse.xsd_2.2.0.v200606271057/ features/org.eclipse.xsd_2.2.0.v200606271057/license.html features/org.eclipse.xsd_2.2.0.v200606271057/eclipse_update_120.jpg features/org.eclipse.xsd_2.2.0.v200606271057/feature.properties features/org.eclipse.xsd_2.2.0.v200606271057/epl-v10.html features/org.eclipse.xsd_2.2.0.v200606271057/feature.xml yadda, yadda...
Note you are not distributing a full version of WTP only a verbatim copy of the pre-requisites you require for hibernate tools to function. The extra files would probably account for less than 200K in the HibernateTools distribution.
If you are going to re-distribute features from WTP at least do so in their original form not a bastardized version. The original form has both plugins/* files and features/* files. This way you can correctly make use of <import ...> and break away from <plugin ...>.
For update site purposes you simply mark out in the site.xml all the available features from that download site.
For sorceforge download purposes you simply include the relevant features/* files in the HibernateTools-XYZ.zip
Then you are compatible with the way the original feature was distributed.
Ideally your update site has each feature in a seperate JAR file and the site.xml and update manager works out a list of files it needs to satisfy all pre-requisite requriements (for fine grained downloading). But the first step on the road to that is to properly re-distribute your pre-requisites so they can be detected and seen as equivalent features by the platform.