Comment 1 David Williams 2008-05-10 23:07:06 EDT

Created attachment 99625 [details]
for features diff: graphic showing "diff" between the two installs.

Comment 2 David Williams 2008-05-10 23:08:31 EDT

Created attachment 99626 [details]
plugins diff: graphic showing "diff" of plugins between the two installs

Comment 3 John Arthorne 2008-05-12 10:42:01 EDT

First, I'm not sure how to read the diff output in the attached screen shots. The two lists look the same to me. Can you point out the differences, which features are missing?

If there are differences, it's likely due to the fact that "Select Required" in Update Manager was broken. UM didn't have enough information to perform precise dependency resolution, as p2 is capable of doing. p2 can detect, for example, package or bundle imports/exports that are not expressed in the feature.xml. In short, it "automatically finds minimum required prerequisites", as you requested in bug 123010. See also bug 146253 and its duplicates for related discussion on the incorrect behavior of "Select Required" in UM. We don't intend to reproduce this broken behaviour in p2.

Here's the simple test: are there any unsatisfied dependencies in the features/plugins that were installed by p2 in your case? If the JEE feature is installed, and all of its dependencies are satisfied, then I don't think we have a bug here.

Comment 4 David Williams 2008-05-12 11:43:25 EDT

(In reply to comment #3)
> First, I'm not sure how to read the diff output in the attached screen shots.
> The two lists look the same to me. Can you point out the differences, which
> features are missing?
> 

The feature lists are both the same, the '+' in the folder indicates those folders are installed when using UM (and the "-" indicates they are not there for the p2 install). 

The plugin lists are similar ... everything is listed, and + and - indicate present in one, missing from the other. In this case, there is a little bit of a mix (the P2 version did install some plugins the UM did not). 

(cases where the feature/plugin was present in both are not listed at all). 

Comment 5 David Williams 2008-05-12 12:19:57 EDT

Thanks John, 

It seems then this blocking bug belongs back with us then, and we'll have to change our feature definitions based on this change in behavior (broken or not, that was the behavior, and now we have to react to the change before we ship, and hopefully our adopters can adjust). 

Where we used to use plugins where ever we could in feature dependencies -- I thought that was what you recommended -- we will now
have to change to specify features, where we want the whole feature. (regardless of whether or not another plugin requires something in it, such as for 'documentation bundles' which are only required by features). 

Do you think others are aware of this change in behavior? Would a note to cross-project be in order? Perhaps a word in a migration guide? Who knows maybe we're the only ones effected. 

Comment 6 Pascal Rapicault 2008-05-12 13:41:59 EDT

Know that in the future (post 3.4) we will try to provision the doc automatically based on a user's preference and what is installed.

Comment 7 John Arthorne 2008-05-12 14:11:20 EDT

The question is, do you really want/need those prerequisite features to be there?  If EMF, for example, only has certain plug-ins installed because they are required by WTP, perhaps the EMF features and all the stuff they bring along don't need to be there. It may not even make sense for the user to see documentation for these features, if they are purely implementation details. As a fictitious example, just because I make use of "draw2d" in one of my plug-ins to perform drawing, does not mean I want draw2d documentation to appear for my end users.

In general, I still believe expressing dependencies at the plug-in level is preferable if you don't actually need the entire feature. Of course, if you really want the entire feature to be there, express the dependency on the feature. But, keeping dependencies more fine-grained helps to avoid the bloat we so often experience in our products, where we end up consuming large wads just to get access to some small piece of functionality.

This is definitely something to mention in the migration guide - I have made a note of this for our documentation pass.

Comment 8 David Williams 2008-05-12 15:22:21 EDT

(In reply to comment #7)

> In general, I still believe expressing dependencies at the plug-in level is
> preferable if you don't actually need the entire feature. 

Ok, your are right that for things like draw2d and the emf ones we don't want/care about the docs ... but, that leads to my next question ... hypothetically, let's say an emf plugin needs some service 6 months after release, how does an end-user get that service if we have no emf feature? I'm assuming "feature patch", or some thing similar for P2 is still the way service is delivered ... I thought a feature patch sort of assumed a feature be present first ... does this mean we (WTP) would have to prepare a feature.patch for emf.plugins if there was some service our users needed? 
That sounds complicated and bound for trouble. 
(as well as not being very componentized). 

Any insights? Any P2 solutions I haven't heard about? 

Comment 9 David Williams 2008-05-12 22:49:12 EDT

Just thought I'd document some of my (slowly returning) memory about how we in WTP ended up where we did. Our original design _was_ to specify features in many of our pre-reqs, such as (in simplified form, where higher items in hierarchy depend on the lower level features) 

jee.feature
   ejb.feature
   basics.feature
   jeeservers.feature
   webdevelopment.feature
      xml.feature
      webservices.feature
      common.feature
      server.feature
      javascript.feature

But ran into limitations with update manager that if we expressed a dependency as a feature, then the feature _had_ to appear in the site.xml file. 

This wasn't appropriate for many of our "component features" and would just clutter up the Update Manager UI (we had many many more than what's listed above :) 

So it appears that this is not required in the P2 and additional features just appear in "uncategorized" category, but do not have to explicitly be listed in any site.xml file. 

Please correct me if I'm wrong. 

Comment 10 John Arthorne 2008-05-12 23:01:48 EDT

>So it appears that this is not required in the P2 and additional features just
>appear in "uncategorized" category, but do not have to explicitly be listed in
>any site.xml file. 

Well, our current thinking is that it was a useful "feature" of UM that features could be hidden by omitting them from site.xml. I didn't realize that UM would fail to install such unlisted features.

We have a bug in p2 to hide features in the UI if they are unlisted in site.xml (see bug 227675).  Regardless of whether we fix that, p2 certainly won't require features to be listed in site.xml (p2 repositories don't even have a site.xml - we just leave that intact for backwards compatibility with non-p2 based clients).

Comment 11 David Williams 2008-05-14 04:05:51 EDT

Just to document it here, in some offline chats, Pascal confirmed that in the Ganymede release, the use of feature.patches will (still) be the way service is applied off cycle. 

That might effect how we want to define some of the dependancies, such as if we day "draw2d" bundle only, then if GEF ever provided a feature patch for that plugin, our users would not get it applied automatically. They'd first have to go and install the full GEF feature and then install the patch. Easy to do, but hard to know about (and explain). 

Comment 12 John Arthorne 2008-05-14 11:03:59 EDT

I suggest being very careful about feature changes this close to the release. The advantage of the changes seems small compared to the disruption. One option with minimal disruption would be to create a new "all in one" feature that requires all the features that you want to have present in a typical user install. I.e., don't touch your current features, but add one or two new ones for the "install from Ganymede" use case. It looks like EMF has taken this route, and it gives the user flexibility of picking and choosing the bits they want, or just "take everything" if they don't care or don't have the expertise to figure out what they want.

Comment 13 David Williams 2008-06-05 14:08:15 EDT

Just to document progress and plans here, I have started work (in a side branch) to change our feature definitions so they always use features to specify "dependencies". It's sort of tedious (since no handy 'compute' tools for features), but for the most part is straight forward. For the platform, that's pretty obvious (org.eclipse.platform, and/or org.eclipse.jdt features). Anywhere we needed gef (or draw2d) plugins, I'll use the org.eclipse.gef feature. For emf, I'll use the "smallest" emf feature that contains the emf plugin we depend on, not the "all inclusive" emf feature, but the ones that (nearly) have one plugin per feature. 

So, for example, for our xml_ui.feature, the requires list becomes as follows: 
   <requires>
      <import feature="org.eclipse.xsd" version="2.4.0"/>
      <import feature="org.eclipse.xsd.edit" version="2.4.0"/>
      <import feature="org.eclipse.gef" version="3.4.0"/>
      <import feature="org.eclipse.platform" version="3.4.0"/>
      <import feature="org.eclipse.emf.common" version="2.4.0"/>
      <import feature="org.eclipse.emf.ecore.edit" version="2.4.0"/>
      <import feature="org.eclipse.emf.edit.ui" version="2.4.0"/>
   </requires>

For the most part, I'll try to be redundant for these ... not sure it matters one way or the other, but seems conceptually clearer ... for example, even though xml_ui.feature _includes_ xml_core.feature and xml_core feature requires platform, and org.eclipse.xsd, etc., I'll try to list the requirement in both places (unless I hear or discover that redundancy causes problems). 

Using the side branch, I'll make these changes for all the wst and jst features for which I have commit rights, make sure that still builds ok, and then try some "update" scenarios with results (on my "local" machine). If all that looks as expected, I'll submit patches for JSF and Dali features (if needed), update this bug, and request review. 

Unfortunately, I won't be at that review point until Friday, or maybe even Monday :( 

I _think_ it'll be relatively safe but will also want to review with adopters to be sure there's no subtle assumptions or interactions. 

Comment 14 John Arthorne 2008-06-05 15:05:32 EDT

I'm bummed by this move towards coarser-grained dependencies. If we really wanted the old behaviour of always obtaining content at feature granularity, we could implement this with the metadata we have available (the p2 resolver could be tooled to do the grunt work of finding the smallest feature set containing the required functionality). 

I think this is something we'll be exploring in the next release of p2: handling both the "give me a complete product that includes X" use case of wanting groups of complete functionality (content+doc) versus the "give me the bare minimum I need to run X". I recognize that you are looking for the first case ("complete product"), but the changes here will prevent the second case ("bare minimum"). Since we don't have a good answer to how to handle these two cases in 3.4 release, I suppose you'll need to do what's necessary to get the behaviour you want. Just don't be surprised if next year we start recommending people do the exact opposite of the change you are making now ;) ... on second thought you're probably already used to this ;)

CCing Jeff who is interested in all topics related to components and right-grained provisioning.

Comment 15 Jeff McAffer 2008-06-05 17:14:43 EDT

Thanks for adding me John.  I agree that both usecases are important.  There are cases where currently (and likely in the future) the expressed constraints are insufficient.  For example, take the Help system.  We do not spec that an HTTP service is needed to run help successfully.  So the hapless user picking on some bundle that requries the help bundle will not get a functioning help system.  What they really should have said is that they need the Help Feature (yuckie from a componentization point of view) or the help components should have fully expressed their dependencies (hard in the general case).

One thing we are doing in the EPP wizard case is presenting the user with a set of parallel metadata that has the coarse grained dependencies.  So if they pick something high up in the stack to install but all the dependencies are spec'd on a bundle basis, they will still get all the containing features.  This is crappy but the separation is ok.  That is the producers still spec'd their dependencies as they see them.  The system integrators (EPP) crafted additional dependencis and exposed them to their users for installation.

Anywya, this should be a topic for p2 in the next release

Comment 16 Martin Oberhuber 2008-06-06 09:09:59 EDT

We are hit by this problem too, and I'm afraid that for TM I don't see the possibility of creating a "feature dependencies" workaround like Dave is about to implement for WTP. Here is what happens to us:

* On Ganymede site, user selects "C/C++ Remote Debug Launcher", not knowing
  that it depends on RSE, and asks to install.

* P2 uses the plugin dependencies, and installs the RSE "Core" plugins that
  this depends on. BUT

  --> Only RSE Core bundles are installed, not any of the "connection" 
      extensions like ssh, dstore. So, the feature is totally unusable!
  --> Like Dave noticed, RSE Userdocs are not installed.
  --> Like Dave noticed, RSE "Core" features are not installed; only the plugins.

Now I thought about implementing a workaround like Dave, and adding a feature dependency from Remotecdt Launcher into the "RSE Runtime" feature that provides ssh, dstore, ftp connectivity along with User Docs, and that had been auto-selected by Update Manager in the last release. 

But I'm afraid I cannot do that, because in our Commercial product, we do want to install the RemoteCDT feature, but we do *not* want to install the dstore feature. So, having a REmoteCDT -> RSE-RUntime -> RSE-DStore feature dependency / inclusion chain, would render our commercial product's configuration invalid! And if we fixed that by creating a custom variant of the REmoteCDT feature, we could not "check for updates" it any more!

At this point, I'm clueless how to solve the situation. The core difference between UM and P2 that matters here, seems to be that by means of the site.xml file specifying granularity for the install in UM, the Ganymede site.xml automatically had some kind of "Product definition" that goes beyond the plain bundle dependencies.

By interpreting a bundle dependency as "give me the smallest possible set of features that are listed in site.xml and include all bundles required", UM automatically placed another layer on top of the bundle dependencies, which ensured that the install was correct from a "Europa Product" perspective. What's more, by providing the separate "Select Required / Review / Install" steps in UM, it gave the user additional option to review the features to be installed and potentially change them (e.g. change RSE-Runtime into RSE-SDK if desired).

P2 doesn't offer these two options any more:
1.) Instead of "Review entire feature list", P2 only offers the selected root
    features to review and hides the details of what bundles have been computed
    as dependencies.
2.) Instead of "Always install from an update site in the feature granularity
    specified by that site", P2 now only has bundle dependency which is 
    sometimes correct, sometimes not. The additional granularity specification 
    step that the site.xml provided seems to be missing.

If anybody has an idea what I could do to address the issue, please let me know!

Comment 17 Martin Oberhuber 2008-06-06 09:11:07 EDT

PS Is it true that "Check for Updates" can only update bundles that are contained in a feature? Or can P2 also update "stand-alone" bundles that do not have a containing feature but were installed in order to satisfy requirements of some other feature only?

Comment 18 Pascal Rapicault 2008-06-06 10:00:23 EDT

It seems to me that you have crafted your dependencies around the disputable behavior of update manager that consisted in finding "a" feature (see comment #3). Also I would like to add that the "requirement construct" was to allow for the required things to be installed independently of the "requirer". Thus in situations where the required things were already there no checks were being done and the same situation could have happened. In short the installation of the "Remote CDT launcher" could have failed in the same way with UM.

> So, having a REmoteCDT -> RSE-RUntime -> RSE-DStore feature dependency / 
> inclusion chain, would render our commercial product's configuration invalid!
> And if we fixed that by creating a custom variant of the REmoteCDT feature, we
> could not "check for updates" it any more!
    Could you detail why, the "check for updates" would not work?


> 1.) Instead of "Review entire feature list", P2 only offers the selected root 
> features to review and hides the details of what bundles have been computed
> as dependencies.
    This simplification is in response to corporate customers where the user is scared of seeing all these details.

> 2.) Instead of "Always install from an update site in the feature granularity
> specified by that site", P2 now only has bundle dependency which is sometimes 
> correct, sometimes not. The additional granularity specification step that the 
> site.xml provided seems to be missing.
    It seems to me that the real problem is in the way that dependencies are setup, in the implicit "product configuration" role that was associated with the content of the site and with what is offered to the user for installation. It seems to me that this layer of "product composer"/"system integrator" is missing and in the context of Ganymede, we may need to publish features that represent this integration. 

> P2 now only has bundle dependency which is sometimes correct, sometimes not.
   p2 uses the dependencies available in the manifest and in the features. If those are incorrect it is an authoring problem, not a p2 problem. That said there is a very specific situation where miss-specified dependencies expressed in features can lead to missing dependencies and this can be seen in bug #225340.

Comment 19 Pascal Rapicault 2008-06-06 10:05:55 EDT

> PS Is it true that "Check for Updates" can only update bundles that are contained in a feature? 
  p2 will check for updates on all the things that have been explicitly installed. Checking for more would likely be relatively easy but we did not implement it as the resulting model may feel weird for the user.
However on any provisioning operation (install or update) p2 always tries to install the highest version of any plug-in (satisfaction of dependency pending).

Comment 20 Martin Oberhuber 2008-06-06 10:07:51 EDT

(In reply to comment #18)
> It seems to me that this layer of "product composer"/"system integrator" is
> missing and in the context of Ganymede, we may need to publish features that
> represent this integration. 

Ah! Do you mean this: Create a new feature

  "RemoteCDT for Ganymede"   which INCLUDES original RemoteCDT, and
                                   REQUIRES feature RSE-Runtime

in order to bring back the same functionality that we've had with UM; but, at the same time, our commercial product can include the original 'RemtoeCDT' feature but not the 'RemoteCDT for Ganymede' feature.

This seems to make sense, appears to be a viable solution, and seemingly brings in exactly the "product composer" / "System integrator" layer that's currently missing -- without compromising the underlying original feature contents.

Thanks for this suggestion! I hope I got it right ?!?

Now, based on this approach for a solution, my question from comment #17 is likely not relevant any more, and the strategy that you outline in your comment #19 makes sense. Thanks!

Comment 21 Martin Oberhuber 2008-06-06 13:22:41 EDT

(In reply to comment #20)

I'd like to get some comments on whether we think this is the right approach: Keep the existing featre->bundle dependendencies exactly as they are, but for Ganymede add another layer of "Ganymede specific" features on top of it in order to convey the feature->feature dependencies needed to get Userdocs installed and the like.

Also, I'm thinking a bit about what those "Extra Layer" features need to look like: 
  * Do they need a branding plugin? (likely yes, re-use the branding plugin
    of the underlying wrapped feature, because otherwise neither the wrapping
    feature nor the wrapped feature would show in the About dialog as per bug
    235941.

  * Do they need full license, about, feature update license, Eclipse.jpg
    image and all that stuff that blows up our feature jars -- or could it
    be a plain feature.xml that delegates to the wrapped feature for all 
    the other stuff? - For me it looks like wrapping feature must be a complete
    clone of the wrapped one including ALL its files

  * Do the Project Update Sites need to list the wrapping features or is it
    sufficient to have them on Ganymede only? - I'm not sure about this, 
    but given that the wrapping features improve the "Initial Install" use
    case I assume that they need to be on the project sites; and should perhaps
    be called like "Remote CDT Install Helper"

  * Should we try to hide the fact that there are wrapping features, by
    giving them the same name exactly as the wrapped features? Probably yes;
    Probably rename the wrapped features "...implementation" in order to
    make them distinguishable?

I'm still not 100% sure if wrapping features is the right way to go here, since it looks like we (or at least I) will have to create lots of such wrappers -- basically one for each feature that is a candidate for getting picked as initial install, but isn't self-contained.

One important question in this context is whether it is true that P2 doesn't require us expose the "micro features" in the site.xml any more, because P2 is capable of updating bundles even if their containing feature is not listed in the site.xml; thus making the site.xml really the specification of which "initial features" are intended to get manually picked by users. Is that correct?

One added complexity for my project at least is, that our Ganymede (3.0) release is still fully compatible with Europa and I'd like to encourage people to update even if they keep their Platform at 3.3 -- so, my update site must be usable correctly for both UM and for P2. 

And BTW, given that "Upgrading from Europa to Ganymede by means of UM" was at some point named as something we'd like to support (or am I wrong)? Likely all projects need to prepare their features and sites in a way that both UM and P2 can handle it. Is that even possible?
> (In reply to comment #18)
> > It seems to me that this layer of "product composer"/"system integrator" is
> > missing and in the context of Ganymede, we may need to publish features that
> > represent this integration. 
> 
> Ah! Do you mean this: Create a new feature
> 
>   "RemoteCDT for Ganymede"   which INCLUDES original RemoteCDT, and
>                                    REQUIRES feature RSE-Runtime
> 
> in order to bring back the same functionality that we've had with UM; but, at
> the same time, our commercial product can include the original 'RemtoeCDT'
> feature but not the 'RemoteCDT for Ganymede' feature.
> 
> This seems to make sense, appears to be a viable solution, and seemingly brings
> in exactly the "product composer" / "System integrator" layer that's currently
> missing -- without compromising the underlying original feature contents.
> 
> Thanks for this suggestion! I hope I got it right ?!?
> 
> Now, based on this approach for a solution, my question from comment #17 is
> likely not relevant any more, and the strategy that you outline in your comment
> #19 makes sense. Thanks!
> 

Comment 22 David Williams 2008-06-09 13:09:34 EDT

As for the WTP specific parts of this bug, 
I'd like to start introduce these changes into our WTP RC4 build (due to tomorrow). 

If anyone want to examine the changes, I've done the work in a side branch, called david_williams_tempTests2, and effects only (some of) the feature projects, (plus, I made some changes to the builder project itself, just to help me get through the testing in an incremental way). 

And, if you do review the changes, you might notice I'm not perfectly consistent, but focused on those cases that can (currently) be installed "by themselves" from the update software site: JavaScript (JSDT), XML, Web Development, JEE Development. (I have yet to look at Dali (JPT) ... I've opened bug 236278 to track that. 

This "inconsistency" effects two hypothetical cases: as one example, if someone wanted to installed jst.server core _only_ from an update site, then it might not pull in all the desired _features_ ... but, that's not an option, so we'll worry about it later. The second hypothetical is that if/when we ever move to a "pure" P2 based build, then I think we'll need more exact specification of dependencies, where as not we just leave some blank, since we download and install big zips of pre-reqs, instead of pulling exactly what's in dependencies sections. 

While last minute, this should only effect feature definitions, and update manager install behavior, not executable code per se, so "testing" will be relatively easy ... we'll just install from various sources, and make sure all the installs include the same plugins/features. 

I've tested this some (on a "local" udpate site, produced by "local" builds) and mostly checked that all of XML was installed, when only JEE selected. This test passed, but we'll want to do more systematic testing once in a build (and I would not be too surprised if we needed some post RC4 tweaks to fix cases I've overlooked). 

Still, would appreciate PMC review/approval to verify everyone agrees with this late minute change. The consequences of not doing so is that installs would be incomplete, which is bad enough by itself, but my main concern is that it would mean "patch maintenance" would not work for end-users or adopters (if they happen to use a P2 based pull to include our stuff). 

Comment 23 Raghunathan Srinivasan 2008-06-09 13:26:44 EDT

Agree this needs to be addressed.

Comment 24 David Williams 2008-06-09 13:28:36 EDT

Oh, and meant to mention another complication and case to test. 

I think once we make these changes then the "classic" update manager will no
longer work. At least with out desired site.xml file. As I mentioned in comment
#9, there were some problems last release when using our feature-only
dependencies ... it turned out that all features have to be explicitly in a
site.xml file, for them to be findable by classic UM. 

So, the question is, do we _have_ to support classic UM? 
Does anyone care? 

My proposal would be to address this need, if required, by having a separate
site.xml file, say, "classicsite.xml" that would list everything (Even though,
sort of cluttered, it would work). We would need this only on our WTP site, if
needed at all ... I think. 

I'm just adding this comment, since I don't know what the requirement/need is
for classic update manager functionality, and thought others might have an
opinon. 

Comment 25 Mik Kersten 2008-06-09 13:39:18 EDT

(In reply to comment #24)
> I think once we make these changes then the "classic" update manager will no
> longer work. At least with out desired site.xml file. As I mentioned in comment
> #9, there were some problems last release when using our feature-only
> dependencies ... it turned out that all features have to be explicitly in a
> site.xml file, for them to be findable by classic UM.

David: is it possible for you to have both plug-in and feature dependencies in your standard site.xml, or does that break?  That's what we currently have with Mylyn and are in the process of testing (so far so good).  For our 3.3-specific update site we are excluding the feature dependencies as we did for Europa.

Comment 26 Neil Hauge 2008-06-09 16:35:18 EDT

+1 for WTP changes.

Comment 27 David Williams 2008-06-09 23:56:29 EDT

For those interested, I've opened bug 236353 to track the need to have "bundle oriented" maintenance. 

Comment 28 David Williams 2008-06-10 08:30:51 EDT

Fixes released for RC4.
If there are post RC4 tweaks required, will open new bug. 

Comment 29 David Williams 2008-06-10 08:36:14 EDT

(In reply to comment #25)
> (In reply to comment #24)

> David: is it possible for you to have both plug-in and feature dependencies in
> your standard site.xml, or does that break?  That's what we currently have with
> Mylyn and are in the process of testing (so far so good).  For our 3.3-specific
> update site we are excluding the feature dependencies as we did for Europa.
> 

Not sure. I think if we had both, UM would still need to have the feature in a site.xml file, so not sure that would help. I'll test with final/official RC4 Ganymede site to see what effects are. 

It is a "hole" in Ganymede plan, though, that we haven't specified if we need to support both. Not sure why anyone would need the old UM (but, am willing to learn why). I don't mind supporting both, if really required, but don't' want to just assume we need to and do a bunch of work that's not really required.). 

Comment 30 Martin Oberhuber 2008-06-10 09:21:25 EDT

Uhm, anybody thinking about upgrading Europa to Ganymede through UM? Wasn't that a hot topic back in the Europa days? That would be using old UM.

Comment 31 Martin Oberhuber 2008-06-10 10:01:24 EDT

(In reply to comment #21)

I'm afraid this was not the right approach. 
I need to give up on the "wrapper feature" idea. After fighting PDE
Build for approx 16 hours now, I do not find a way of having the
wrapper features generated, and still getting source plugins 
generated.

It looks like I will have to introduce some feature dependencies,
although this limits the flexibility in which products can be
created.

I must say, this "specification update" of P2 has cost me
several grey hairs.

Comment 32 John Arthorne 2008-06-10 10:34:43 EDT

Martin, I suggest entering a bug report against p2 for your use case described in comment #16. This is an interesting case that I believe isn't solved well in UM but p2 can actually support with the right metadata. It sounds like it would be incorrect to say "C/C++ Remote Debug Launcher" feature requires the "RSE Runtime" feature.  What it actually seems to depend on is some notion of "connection provider" that both "RSE Runtime" and your commercial offering provide. If this is the case, the "C/C++ Remote Debug Launcher" feature could in theory depend on a "connection provider" capability in the p2 metadata. Both the RSE Runtime and your commercial tool could provide this capability. At install time p2 would then look for a "connection provider" and resolve either the open source or commercial offering depending on what is in the available repositories.  In fact, once p2 API is available, you would be then able to have a "search for connection providers" option in your GUI that could go out and look for additional connection providers at runtime if the user didn't have the provider they needed. This is a bit advanced in the Ganymede timeframe because we lack APIS and authoring tools for p2 metadata, but it is an interesting direction to explore in the future.