Community
Participate
Working Groups
See bug 130502 for the long history of this issue, but in summary ... It is assumed that any "product" defines it's own capabilities, specific to just that product (where product == epp package). There are two steps to this, that I know of. 1. Define a "capabilities preference page". 2. Define the capabilities (activities) as your product (package) wants them. bug 130502 concluded that "EPP would solve this problem" ... but, not sure we have solved that yet, in EPP.
Is there a common solution (or, common pattern) that all EPP packages should use? Is it clear there would never be "interference", if multiple "capabilities preference pages" are introduced?
I think one pattern that would at least mostly work is as follows ... I'm sure there's others, but this is likely how we in JEE IDE would approach it: Define a "jee package feature" which would only ever appear in the JEE IDE Package. It would 'include' the eclipse.sdk _bundle_ (not feature!). That bundle would include the preference page ... and what ever else they define. Plus, the jee packge feature would include the jee package product bundle. While we are not going to do much with our 'product' plugin this release, this would be the place where we should list/define all jee package capabilities ... right? One question .. would this pattern work for products/packages that did not otherwise use/include JDT? What happens to the "java activities" that are in eclipse.sdk bundle, if JDT is not present? (We dont' actually have this problem in EPP, at the moment, be we in WTP have to solve this problem for our stand alone JavaScript and stand alone xml "products". Thanks in advance for any recommendations.
(In reply to comment #1) > Is there a common solution (or, common pattern) that all EPP packages should > use? No, unfortunately not. I wasn't aware of bug #130502, but there is another one (#228517) which is 'kind-of-a-duplicate', and it has been asked before (#191378) to provide a product with each EPP package, but I didn't want to force this in the past.
Could EPP include a feature that itself includes the required plugins from the platform for capabilities? That way you'd only need to install the runtime + this feature in order to also include the capability-enabling plugins erstwhile provided in the platform SDK feature. (For next year, we might want to suggest that the platform split their features into smaller pieces, as EMF did, UML2 plans to do, and PDT is evaluating doing.) This "Eclipse Capabilities Enabler" feature could also exist on the Ganymede site (in "Enabling Features", of course), so that people who've installed Eclipse runtime, not SDK, can update to get this option. -- Of course the other approach -- at the per-project level -- is that if you're a project that requires capabilities, you expose that requirement via your features so that when p2 is looking to install your runtime or sdk feature, it'll resolve those deps and install those plugins.
>> For next year, we might want to suggest that the platform >> split their features into smaller pieces That was asked for repeatedly in bug 130502, the first time more than two years ago. I think it would be great if Platform packaged capabilities (and any other product plugin stuff) in a feature that didn't also include all the source and documentation. But I'm not holding my breath.
This is fixed in Galileo, for Java EE IDE package. See bug 254130 for some of the "re-hashing" of the long term problem. See bug 280566 for how we made a relatively "pure" capabilities plugin. I realize without good triggers, capabilities are of limited usefulness, but hopefully Galileo will be a small step forward and motivate improvements next release. And, well, not to mention at least the preference page will be there for when others distribute Capabilities in their bundles, such as the Clear Case example.
