Bugzilla – Full Text Bug Listing
| Summary: | Unable to patch if optional features are not present | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Steve Francisco <stephen.francisco> |
| Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Dejan Glozic <dejan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P1 | CC: | manahan |
| Version: | 2.0.2 | ||
| Target Milestone: | 2.1 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
Reviewed issue. The problem occurs when the efix feature includes an optional feature. The optional feature seems to be needed in the remote site for the install to work but breaks the activity constraints. 2.1 M4 latest Nightly build allows install if added to the batch update but it installs the optional feature. What Eclipse release do you want the fix in? We can provide the fix in 2.1, but will that work for you? Fix is requires on 2.0.2 stream. We currently have 2.0.2.1 version of the platform plugins. Ack. Since we have identified another critical problem related to e-fixes and there is a JDT bug that is required, we will probably roll 2.0.3 release including all three. Steve, can you attach a sample that you mentioned in the report (the one that demonstrates the problem)? Fixed in 2.0.3, need to move the fix to 2.1 as well. Fixed in 2.1 |
If an optional feature is not installed, an attempt to patch the feature that includes the optional feature fails after pressing the "Install" button with the following message: (X) Requested operation cannot be performed because it would invalidate the current configuration. The details say: <feature name> (version): Older version of feature "optional feature name (version)" must be present for a patch to be applied. I have a simple example of this that I can supply. The feature hierarchy looks like this: + master 1.0.0 (root feature) | '--+ ftrA 1.0.0 (feature that will be patched) | '--- ftrA.opt 1.0.0 (optional feature) So feature "master" includes feature "ftrA" which optionally includes "ftrA.opt". Now if a new patch (fix1) is attempted to install and has the following feature.xml, it will fail as described: <?xml version="1.0" encoding="UTF-8"?> <feature id="fix1" image="wsFeatUpdate.jpg" label="%featureName" provider-name="abc" version="1.0.0" colocation-affinity="master"> <description>fix1 will install ftrA version 1.0.0.1</description> <license url="%licenseURL">This is for test purposes</license> <includes id="ftrA" match="equivalent" version="1.0.0.1"/> <requires> <import feature="master" version="1.0.0" patch="true"/> </requires> <plugin id="fix1" version="1.0.0"/> </feature> Since ftrA.opt is optional, it should be acceptable to update ftrA independent of it. It doesn't seem to matter if the patch="true" attribute is set. This is a blocker because this blocks us from updating our product in the field.