Bug 18243 - Install/Update does not install features correctly into extension
Summary: Install/Update does not install features correctly into extension
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Update (deprecated - use Eclipse>Equinox>p2) (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P1 blocker (vote)
Target Milestone: 2.0 F2   Edit
Assignee: Christophe Elek CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-29 16:29 EDT by Tim Koss CLA
Modified: 2002-06-04 16:01 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Koss CLA 2002-05-29 16:29:52 EDT
In our product (call it OurProd), we have many features that are not installed 
off of the install CD. Some of these features are optional, and some, due to 
licensing issues with other companies, are not allowed to be on the install CD 
at all. Our problem comes in the case where is installed as an extension into 
another product(s), say Prod1 and/or Prod2. Under the current mechanism, any 
features that are laid down with the native installer will get update 
properly, but any features that are brought down with the Install/Update manager 
will end up with the features of the product that was running at the time. These 
features are a part of OurProd, not the product that is currently running. The 
user found out about them because our 'base' OurProd features installed the 
discovery URL's. We need a mechanism to allow a feature to say where it belongs. 
In the case of OurProd, we know that we will have our base features installed. I 
would like any other 'optional' features we have to be able to say that they 
want to be installed with the 'base' feature/plugin.

If this is left as it is now, we can end up in the scenario where OurProd is 
extended into 2 or more products. If the user updates any existing OurProd 
features, these update will be available across all the products we were  
extended into. On the other hand, any new OurProd features that are downloaded, 
will be put in with the product we are running, even though they are OurProd 
features. Now we have the case where the product is 'polluted' with our OurProd 
feature. As well the other product(s) we are extended into will not see these 
features. This is now inconsistent with the experience of updating an existing 
feature in an extension.
Comment 1 Jim des Rivieres CLA 2002-05-30 15:48:14 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.
Comment 2 Tim Koss CLA 2002-05-30 16:52:59 EDT
The proposed tag will meet our requirements
Comment 3 Christophe Elek CLA 2002-05-31 10:31:13 EDT
Fixed and verified in HEAD. Will verify in F2
Comment 4 Christophe Elek CLA 2002-05-31 15:36:40 EDT
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>

Comment 5 Christophe Elek CLA 2002-06-01 11:10:03 EDT
Verified in F2
Comment 6 Tim Koss CLA 2002-06-04 16:01:55 EDT
verified in F2