Community
Participate
Working Groups
There's a number of improvements in feature definitions to consider in 3.1 ... such as to greatly simplify those "delivered" in final products (e.g. no great need for 'model' onces there) but at same time allow components and sub-projects to have their own features for build control. Especially, we need to learn more about "installable units" to see if there's any differences for P2 that we should take advantage of.
Another aspect of this I'm learning about is that apparently the "requires" part of our feature definitions are too redundant with what bundles specify ... most of which are no longer required (it was required in old "update manager" model). See bug 259610 and follow it's proposed change to versioning guidelines document See http://wiki.eclipse.org/Version_Numbering_Galileo_Update
I'm going to start this week soon ... but will try to do in "small steps" to make sure things still build, can be updated, etc., with each change. First step will be to remove some of the 'requires' sections starting with some of the basic features, such as server tools, source editing, and make sure all is well after that. Second step, I suggest, is to define new features that do not make the UI vs. Core distinction, but instead are more along the lines of functionality that people want to actually pick to have installed ... either via update, or adopters selecting packages to include in their products. One important aspect of this is to make sure the features are still "designed for maintenance" ... that is, that patches can be applied on a feature-by-feature basis, in a realistic, meaningful way. Another step, I propose, is to use "product definitions" to better deliver packages that people want to install. Namely, Javascript (only), XML, Web Development, Java EE development. The would be for Galileo update sites, etc., and would allow capabilities to be packaged in their own plugins, etc., but not picked up by adopters. Adopters would still have their own product definitions and pre-req features only (not our WTP products).
When you restructure the feature to better fit the "product definition", please take into account factoring out the Web services plugins into Web services features that reside in the Web services component (rather than in the J2EE component as they are currently). To be moved from org.eclipse.jst.enterprise_tests.feature to a new Web services test feature (say org.eclipse.jst.ws_tests.feature): - org.eclipse.jst.ws.tests - org.eclipse.jst.ws.tests.performance - org.eclipse.jst.ws.axis.consumption.core.tests To be moved from org.eclipse.jst.enterprise_ui.feature to a new Web services feature (say org.eclipse.jst.ws.feature): - org.eclipse.jst.ws - org.eclipse.jst.ws.axis.creation.ui - org.eclipse.jst.ws.axis.consumption.ui - org.eclipse.jst.ws.axis.consumption.core - org.eclipse.jst.ws.ui - org.eclipse.jst.ws.uddiregistry - org.eclipse.jst.ws.creation.ui - org.eclipse.jst.ws.consumption.ui - org.eclipse.jst.ws.consumption - org.eclipse.jst.ws.axis.infopop - org.eclipse.jst.ws.consumption.infopop - org.eclipse.jst.ws.infopop - org.eclipse.jst.ws.creation.ejb.ui To be moved from org.eclipse.jst.enterprise_userdoc.feature to a new Web services user doc feature (say org.eclipse.jst.ws_userdoc.feature): - org.eclipse.jst.ws.axis.ui.doc.user - org.eclipse.jst.ws.consumption.ui.doc.user - org.eclipse.jst.ws.doc.user
I've released a number of features with the "requires" element removed completely. That should allow some test/confidence that all still works as expected, as we approach M5.
David, please keep Keith in the loop on this RFE as well.
I think the four "depends on" bugs I've just added would make the right organizing features for WTP, basically having 4 downloads, Javascript only, XML IDE only, Web Development, and JEE Development.
mass change back to default assignee and qa contact. I'm not saying I won't work on some :) ... but, won't be all ... so, I think defaults would be best to start over.
