Summary: | Install/Update does not install features correctly into extension | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Tim Koss <tim_koss> |
Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Christophe Elek <celek> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | blocker | ||
Priority: | P1 | CC: | dejan, jeem, klicnik |
Version: | 2.0 | ||
Target Milestone: | 2.0 F2 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Tim Koss
2002-05-29 16:29:52 EDT
Proposed solution: Allow a feature to state an "affinity" for another feature. This would be done with an new, optional "colocation-affinity" attribute on the <feature> element; the value would be the id of the feature that this feature would prefer to be co-located with. E.g., <feature id="com.example.wsdd.extrafeature" colocation-affinity="com.example.wsdd.baseFeature" ...> would indicate that this feature (com.example.wsdd.extrafeature) would prefer to be located in the same local site (eclipse extension install or eclipse product install directory) as the feature named "com.example.wsdd.baseFeature". The affinity is viewed as a suggestion, or hint - not as a constraint: - the user should be able to override this suggestion (ordinarily they would not) - it is no crime to actually install the feature in opposition to its stated affinity - if the feature is already installed somewhere, updates will gravitate to that site regardless of any stated affinity to other features - if the other ("com.example.wsdd.baseFeature") feature is already installed at one local site, then the suggestion chooses that sites over others - if the other feature is already installed in more than one local site (same version in different sites, or different versions), then the suggestion is narrows the choice to these sites but not further - if the other feature was not already installed (and was not being installed), then the suggestion is moot The changes required to implement this feature affect both the update core and the update UI. A user could hand edit the feature.xml in the short term; long term, the feature editor should provide support for displaying and setting the affinity attribute. The proposed tag will meet our requirements Fixed and verified in HEAD. Will verify in F2 Built JAR file, replaced JAR from 20020531, works fine Will still check with F2 I have 2 features. I installed Feature 1 in another Site than platform:base Restart Attempt to install Feature2. The newly created site appears selected Cancel Attempt to install another feature. Platform:base is selected <?xml version="1.0" encoding="UTF-8"?> <feature id="org.eclipse.update.core.feature1" label="Product Feature" provider-name="Smart Company" version="1.0.0"> </feature> <?xml version="1.0" encoding="UTF-8"?> <feature id="org.eclipse.update.core.feature2" label="Extension to Product Feature" provider-name="An even Smarter company" version="1.0.0" colocation-affinity="org.eclipse.update.core.feature1"> </feature> Verified in F2 verified in F2 |