Community
Participate
Working Groups
If feature A is included as part of feature B, there is no way to update feature A independent of feature B using the Available Updates page as feature A will not be listed under the Query settings. Even if feature A is added independently at first, as soon as it is included in another feature we can no longer update it independently. In our product we have the case where we have base tooling that we want to ensure is loaded when a given runtime is added via the update mechanism. The same tooling is pointed to from multiple runtimes. We are using the include tag to get the tooling in, but we want to be able to update the tooling feature separately.
You are using inclusion for dependency control, and that is against the current Update design. A feature that requires plug-ins from another feature should use 'requires' clause instead. Bottom line: 1) Use 'requires' for features that can be individually updated but depend on each other. Eclipse SDK uses feature attribution plug-in for that purpose. Each feature has a plug-in that carries NL info, license, about etc. that has the same ID as the feature. We simply specify dependency on that feature. PDE depends on the platform and JDT plug-ins, for example. 2) Use 'includes' to organize features hierarchically. In this scenario, only the root feature can carry update information and the entire hierarchy must be updated from the same update site. The reason for this is to ensure that service/support contracts are valid - i.e. that only features that are tested and verified to work with each other is installed and configured. In other words, 'includes' is used to form a product hirerarchy. We are currently exploring ways to provide for definition of product suites, where multiple products can be combined into a loose collection (suite) that is delivered as one but retain more independence than it is the case with features that form a product. At the moment (with the 2.0.0/2.0.1 code), the only way to do that is to define each product as a root-level feature. You can use 'requires' to ensure cross-dependence and each root feature can be individually updated, there is no way to represent the collection as an entity - each feature acts independently.
The problem with 'requires' is that it points to a plugin, not a feature. It is pretty much impossible for a user to figure out what feature they need to load to meet the requirements
Granted, but if you use a require to point to the attribution plug-in, the plug- in and a feature have the same IDs and names, which makes things easier. The idea with plug-in require was that features are plug-in lineups and your real dependency is on plug-ins. Consequently, the plug-ins you require may be in many different features. The require statements simplys says 'as long as these plug-ins are installed, I am happy, and I don't care which feature dragged them in'. In reality, we realize that dependency on a feature is more practical in most cases.
I agree that ultimately the dependency is on a plugin and that you don't care where the plugin comes from. Unfortunately, the user is just trying to load a feature here and will be unable to due to a prereq that they will have no id of how to find since the error message shows the plugin id that has no relation to the list of features that the user can see. In our case they get an error message like: WCE JCL Max Class Library (1.9.510): Feature requires plug-in "com.ibm.ive.j9.custom". How the heck can we get the feature name in this message to let the user have a chance to figure it out?
I have to check again, but I think that in 2.0.0 you are notified about the missing prereq and offered a way to search for features that contain missing plug-ins. In your case, if the user chooses the 'Search' option when notified about the missing "com.ibm.ive.j9.custom" plug-in, the search would turn out some results. Did you try this?
Tim, if we were to add another attribute to the 'import' element in feature.xml ('feature') allowing you to specify requirement on a feature rather than on a plug-in, would that fix your problem?
I think that would help a bit - at least the user would know what feature to load, but what I really want is to have the ability to specify other features (that I own and know what site they are on) I want loaded. I want these to get loaded and to exist as if the user loaded them all separately. Let me try to describe the scenario (since I owe you this anyway <g>). We have the case in our product where we supply java class libraries and eclipse based tooling. The libraries are intended to run in a number of different os's and devices, and the tooling is there to help you manage the complex relationships. The tie between the tooling and the libraries is a descriptive meta data. The meta data is backwards compatible, so there is no version relationship between the different features we want to load (i.e. after we load them, they can be updated independtly of each other). I think that what we need would may be provided by what you have described in your suites. To try to restate the scenario simply. To use our product the user has to download Feature A and Featue B independtly. They show up everywhere as a 'top level' feature that can be updated on it's own (with the quick update mechanism) and has no real dependency on the other feature. We simply want to be able to say - if you load Feature A, we will load Feature B as well. In our case there could be many version of this, where Feature A is the tool and Feature B thru Z are the libraries. All of Feature B thru Z would also want to load Feature A
I can see how suite support (the addition of 'match' rule that allows included features to 'grow' and still be correctly resolved) would help you. However, since you indicate that they are completely independent, there may be a limit how high a version of the included feature can be tolerated. Right now, Update does not support updates between major releases. By default, only service increments (i.e. match=equivalent) are treated as 'updates'. This can be bumped up to include minor increments (i.e. match=compatible) in the Preferences. The intended implementation is to follow this restriction, which means that you can specify match=greaterOrEqual in the feature.xml, but search will reject major release increments. Is this too restrictive for your case?
*** This bug has been marked as a duplicate of 21351 ***
