Community
Participate
Working Groups
Several EFixes were applied to individual features, and then a large patch applied to the root feature and many many subfeatures. Since the first couple EFixes did not increment the root feature version (as suggested by bug 27171) there are now many configuration warnings. It is too late the follow the fix in bug 27171 as the EFixes are already out.... Can be reproduced by installing new features, one root feature and a subfeature of that. Apply a patch through update manager on the subfeature, and increment only the subfeature version. Then install another patch that increments both the root feature and subfeature versions. There will now be 2 versions of the subfeature enabled, which will show up in the install configuration and eclipse\workspace\.metadata\.config\platform.cfg.metadata\v2Config*.xml file. Update manager should conceivably check at install time of an update for any older features that were patched and disable them. Update manager correctly disables older features that were not patched, but the patched features are left enabled. The root of the problem is in eclipse\workspace\.metadata\.config\platform.cfg.metadata\v2Config*.xml file, which has the same feature (at different versions) set at configured = "true", when only the highest level should be configured. A hackaround is to set the lower versioned feature to configured = "false" and restart the workbench. This is not exactly the solution I want to give to customers. Has this come up before, and is there a more viable workaround? Ship date for this (Wbi Message Brokers) is quite soon, so any advice would be nice. Thanks
<quote> Update manager should conceivably check at install time of an update for any older features that were patched and disable them. Update manager correctly disables older features that were not patched, but the patched features are left enabled. </quote> Are 'older features that were patched' included in their e-fixes using 'match="equivalent"' or 'match="compatible"'? We have a test where a new e-fix patches a feature already patched by another e-fix, and it works nicely providing that the older e-fix allowes it using 'match='equivalent/compatible'.
all EFixes are released with match="compatible", so this shouldn't be a problem.
I'll add some actual data in, maybe the error will show up. Product is at version 5.0.1, with top-level feature at 5.0.1. Top level feature has subfeature at 5.0.1. Top level contains: <includes id="subfeature" version="5.0.1" optional="false" match="equivalent"/> Subfeature has the following feature.xml (truncated): <?xml version="1.0" encoding="UTF-8"?> <feature ... version="5.0.1" ...> <includes .../> <requires> ... </requires> ... <plugin id="com.ibm.etools.msg.dictionary" download-size="0" install-size="0" version="5.0.1"/> <plugin id="com.ibm.etools.msg.msgmodel" download-size="0" install-size="0" version="5.0.1"/> <plugin id="com.ibm.etools.msg.validation" download-size="0" install-size="0" version="5.0.1"/> </feature> This patch (truncated) is released with this feature.xml for the subfeature: <?xml version="1.0" encoding="UTF-8"?> <feature ... version="5.0.1.1" ...> <includes .../> <requires> ... </requires> ... <plugin id="com.ibm.etools.msg.dictionary" download-size="0" install-size="0" version="5.0.1.1"/> <plugin id="com.ibm.etools.msg.msgmodel" download-size="0" install-size="0" version="5.0.1.1"/> <plugin id="com.ibm.etools.msg.validation" download-size="0" install-size="0" version="5.0.1.1"/> </feature> So we have top-level @ 5.0.1, msg @ 5.0.1.1. Next a CSD is released. Top-level @ 5.0.2, msg @ 5.0.2, which update manager installs after the CSD is unzipped on top. Top-level feature contains: <includes id="subfeature" version="5.0.2" optional="false" match="equivalent"/> With subfeature with similar feature.xml as above, except all versions changed to 5.0.2 In v2COnfig*.xml I get: <feature configured = "true" url="features/subfeature_5.0.1.1/" /> ... <feature configured = "true" url="features/subfeature_5.0.2/" /> And a nice warning on the 5.0.1.1 subfeature in the Install Configuration View, which is no longer a subfeature of the top-level feature, but now indicated as a sibling to the top-level feature.
Why are you creating a patch to update a top-level feature to 5.0.2? Shouldn't you create a normal fixpack?
The upgrade to 5.0.2 is a FixPack/CSD that is installed ontop of existing install (not through an update site). Sorry, maybe I didn't make it clear that the upgrade to 5.0.2 is not a patch, but a FixPack.
Ah dang. This is duplicate of bug 31730, which has been fixed in 2.0.3 and 2.1. Lucky me, I'm stuck on 2.0.2.
*** This bug has been marked as a duplicate of 31730 ***
