Community
Participate
Working Groups
How do we express in metadata that if the user installs IU "A" that we want to suggest to the user that they install IU "B"? In this case, B is not a required capability, but rather a suggested or related capability. Further complicating this is that we may only want to suggest "B" to the user if "C" is installed. More examples and ideas to follow. This bug represents the metadata requirements for these relationships. Bug #247342 discusses the presentation of these relationships.
Some of the use cases: 1) Mylyn bridge for C/C++, where you don't want to show the bridge if C/C++ is not installed. 2) The converse of #1 - You already have Mylyn installed and want to suggest the C/C++ bridge when installing C/C++ 3) Webserver adaptors for the JEE support, where adaptors complement what is being installed to make it fully functional. This means that: a) suggestions can span sites. The suggestion to install Mylyn C++ bridge if you are installing CDT probably originated from Mylyn, yet the user is installing content from the CDT site. b) suggestions must be able to take into account the content and/or properties of the target profile, otherwise we are just making too many bogus suggestions. Pascal suggests that a suggestion is a separate IU much like a category. This lets aggregators compose suggestions independent of the IU provider. The required capabilities in a suggestion IU enumerate the suggested IUs. - is the id of the suggestion IU the id of the IU for which it is making suggestions? - somehow we need to express the conditions under which the suggestion IU is "enabled." The suggestion IU should be able to express IU's that must be present in the profile for the suggestion to be visible, or even property values in the target profile that must be present for the suggestion to be visible (such as platform, etc.)
marking M4 as there are M4 UI bugs that depend on the outcome of this discussion. cc'ing Dave. Dave, Pascal thought you might have some suggestions for expressing the enablement conditions for a suggestion within the metadata.
When we talked about these use-cases in the past, we were leaning towards something automatic rather than a system based on user suggestions. I.e., metadata that could express: If A and B are installed, then automatically install C. Thus the CDT/Mylyn bridge would be installed automatically once both CDT and Mylyn are installed, regardless of which was installed first. Making it implicit has some advantages: the user doesn't need to be aware of or understand the capabilities provided by the bridge plugin, and they may not even be aware of the two features being bridged if they are low level pieces. There may be cases where explicit user interaction is helpful though. A related issue is bug 236111. Someone might want to have the bridge feature already in the install so that it can be enabled automatically once its prerequisite is available.
>Making it > implicit has some advantages: the user doesn't need to be aware of or > understand the capabilities provided by the bridge plugin, and they may not > even be aware of the two features being bridged if they are low level pieces. > > There may be cases where explicit user interaction is helpful though. The problem that continues to plague us is that there is not just one user. Some users would rather not bother with such detail (such as Ellen in the user persona definitions), and others do not appreciate any "magic" that happens for them, for different reasons (Laurel, Dave, etc.). From a UI point of view, one of the big pieces of work for 3.5 is to define these users and then satisfy the users who want to understand the relationships and dependencies involved in an install/uninstall/update without overwhelming those who don't care. As long as we can define what the metadata looks like for these relationships, then we can separately iterate on the UI. It sounds like even in an automatic case, we need a way to not only specify the relationship, but to specify conditions under which the relationship is valid.
We will not be addressing this in 3.5.
(In reply to comment #5) > We will not be addressing this in 3.5. :( :( Could we please get any pointer to how adopters can avoid having the current P2 download large 100% optional dependencies like TPTP, Birt etc. when we provide plugins for these things in our product for the intention to only have these enabled IFF the user installs them ? (i.e. we don't want the user to get these large dependencies enforced on them)
Required capabilities in p2 have a "greedy" attribute that can be set to false, which will avoid those dependencies being traversed during resolution. There is no tooling support for this, but it is possible by directly editing your p2 metadata.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
