Bugzilla – Full Text Bug Listing
| Summary: | [publisher] Produced patches don't match specific feature version numbers | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | DJ Houghton <dj.houghton> | ||||||
| Component: | p2 | Assignee: | Carsten Reckord <reckord> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | blocker | ||||||||
| Priority: | P3 | CC: | daniel_megert, david_williams, konstantin, markus.kell.r, mistria, mn, pascal.rapicault, pascal, pwebster, reckord, stephan.herrmann, walther, zulliger | ||||||
| Version: | 3.7 | ||||||||
| Target Milestone: | 4.14 M3 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| See Also: |
https://git.eclipse.org/r/61056 https://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=3d0b351e0d3f340bcc26f7a651f4eebfc817b722 |
||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 559620 | ||||||||
| Attachments: |
|
||||||||
I don't think this data is that critical for an install, but it should definitely be looked at. Are you going to DJ? Created attachment 200296 [details]
patch (work in progress)
Pascal, what do you think of the patch? Did I introduce the correct range or should it be narrower? DJ, two questions: 1) Why are you generating such a wide range? A patch usually is for a very specific feature, so I think a perfect match would be called for (at least that's the behavior in previous versions) 2) Wouldn't org.eclipse.equinox.internal.p2.publisher.eclipse.FeatureManifestParser.processImport(Attributes) be a better place to fix this? As I see it, the problem here is that a) the feature schema doesn't allow the match attribute together with the patch attribute b) the parser fails to set match=perfect if patch=true Created attachment 213903 [details]
FeatureManifestParser patch
Patch that creates a default match rule ('perfect') for patch base feature
Carsten’s patch works for me, restoring documented behavior. Tested with v20120511-1931 (Juno SR1) and current master. Is there a reason not to at least consider this for Kepler SR2? Seems like an awfully long time to leave patching completely broken. Changing severity to blocker. Will downgrade to critical if I find a viable workaround. Experimenting with changing dependencies in patch plugin such that they only match versions expected in the patch target environment. I was able to workaround this issue by modifying the version constraints in Require-Bundle statements in MANIFEST.MF files in all patch plugins such that they can only match one release of their dependency (such as "[1.1.200,1.1.201)"). This has the effect of making the patch not installable in undesired configurations, which works around p2's failure to match feature version when applying the patch. Will not be addressed in Luna. How about Mars? This effects "me" in bug 475228 while preparing patches for BETA_JAVA9 patches. Bug is still present in Mars.1 and still fixed by Carsten’s patch. New Gerrit change created: https://git.eclipse.org/r/61056 I've just pushed the patch to gerrit, in case that helps: https://git.eclipse.org/r/61056 *** Bug 483686 has been marked as a duplicate of this bug. *** Bug is still present in 2019-09 (4.13) and still fixed by the patch on Gerrit, with some trivial manual conflict resolution. Gerrit change https://git.eclipse.org/r/61056 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=3d0b351e0d3f340bcc26f7a651f4eebfc817b722 Thanks! Looking at the change history since 4.14 M1 this change seems to be the cause that breaks the Object Teams M2 build.
The last build using M1 created metadata for our patch feature like this:
-----------------------------------------
<unit id="org.eclipse.objectteams.otdt.core.patch.feature.group" version="2.7.6.201911031743" singleton="false">
<patchScope>
<scope>
<requires size="1">
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.feature.group" range="0.0.0"/>
</requires>
</scope>
</patchScope>
<changes>
<change>
<from>
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="0.0.0"/>
</from>
<to>
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="[3.20.0.OTDT_r276_201911031743,3.20.0.OTDT_r276_201911031743]"/>
</to>
</change>
</changes>
<lifeCycle>
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="0.0.0" greedy="false"/>
</lifeCycle>
<update id="org.eclipse.objectteams.otdt.core.patch.feature.group" range="[0.0.0,2.7.6.201911031743)" severity="0"/>
--------------------------------------------------
Since upgrading to M1 today, the corresponding data looks like this:
--------------------------------------------------
<unit id="org.eclipse.objectteams.otdt.core.patch.feature.group" version="2.7.6.201911051348" singleton="false">
<patchScope>
<scope>
<requires size="1">
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.feature.group" range="[3.18.200.v20191101-0300,3.18.200.v20191101-0301)"/>
</requires>
</scope>
</patchScope>
<changes>
<change>
<from>
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="0.0.0"/>
</from>
<to>
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="[3.20.0.OTDT_r276_201911051348,3.20.0.OTDT_r276_201911051348]"/>
</to>
</change>
</changes>
<lifeCycle>
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="[3.18.200.v20191101-0300,3.18.200.v20191101-0300]" greedy="false"/>
</lifeCycle>
<update id="org.eclipse.objectteams.otdt.core.patch.feature.group" range="[0.0.0,2.7.6.201911051348)" severity="0"/>
----------------------------------------------------------
The difference being:
<lifeCycle>
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="0.0.0" greedy="false"/>
</lifeCycle>
vs.
<lifeCycle>
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="[3.18.200.v20191101-0300,3.18.200.v20191101-0300]" greedy="false"/>
</lifeCycle>
with the new meta data the build aborts when it tries to install that feature, saying:
[java] Installing org.eclipse.objectteams.otdt.feature.group 2.7.6.201911051348.
[java] Installation failed.
[java] Cannot complete the install because one or more required items could not be found.
[java] Software being installed: Object Teams Development Tooling 2.7.6.201911051348 (org.eclipse.objectteams.otdt.feature.group 2.7.6.201911051348)
[java] Missing requirement: Object Teams Patch for JDT/Core 2.7.6.201911051348 (org.eclipse.objectteams.otdt.core.patch.feature.group 2.7.6.201911051348) requires 'org.eclipse.equinox.p2.iu; org.eclipse.jdt.core [3.18.200.v20191101-0300,3.18.200.v20191101-0300]' but it could not be found
[java] Cannot satisfy dependency:
[java] From: Object Teams Development Tooling 2.7.6.201911051348 (org.eclipse.objectteams.otdt.feature.group 2.7.6.201911051348)
[java] To: org.eclipse.equinox.p2.iu; org.eclipse.objectteams.otdt.core.patch.feature.group [2.7.6.201911051348,2.7.6.201911051348]
I'm aware that feature versions must match, but what's the business of requiring an exact *plugin* version? Was that change made by intention.
(In reply to Stephan Herrmann from comment #18) > Looking at the change history since 4.14 M1 this change seems to be the > cause that breaks the Object Teams M2 build. > [...] > what's the business of > requiring an exact *plugin* version? Was that change made by intention. I don't think this change in the versionRange for the plugin is intentional; at least, I don't think changing it was the goal of this scope (which was only focusing on the "patched" feature). All that is a bit hard to reproduce, especially since OTDT build uses Ant and XSL which aren't trivial to grok. Do you think you could somehow manage to identify a way to reproduce the faulty output in less steps, from the IDE or with command-line directly invokign the p2 applications? I think this shows something erroneous in FeaturesAction line 329 iu.setLifeCycle(MetadataFactory.createRequirement(IInstallableUnit.NAMESPACE_IU_ID, getTransformedId(entry.getId(), entry.isPlugin(), /*isGroup*/true), range, null, false, false, false)); It seems to me that p2 decides to "drill-down" into patch feature content to decide of some extra requirements; however, this is not really desired. But that makes me wonder about your specific case: is the JDT feature already pre-installed before you try to install the patch feature? Isn't the right jdt.core bundle already installed with it? Given the error message you see, assuming the JDT feature and bundle match (ie the specific version of the feature contains this specific version of the bundle) and if they are installed, I think installing the patch should work even with the new metadata. So it might also be an issue in the resolver not handling the lifecycle requirement as expected... So I tried the following
mistria@mistria-rh:~/git/org.eclipse.objectteams/features/org.eclipse.objectteams.otdt.core.patch$ ~/eclipse-SDK/eclipse -application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher -source $(pwd) -metadataRepository file\:$(pwd) -artifactRepository file\:$(pwd) -consoleLog
to generate metadata from the HEAD of OTDT patch feature, and here is what the content.xml contains
<unit id='org.eclipse.objectteams.otdt.core.patch.feature.group' version='2.7.6.qualifier' singleton='false'>
<patchScope>
<scope>
<requires size='1'>
<required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.feature.group' range='[3.18.200.v20191101-0300,3.18.200.v20191101-0300]'/>
</requires>
</scope>
</patchScope>
<changes>
<change>
<from>
<required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.core' range='0.0.0'/>
</from>
<to>
<required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.core' range='[3.20.0.OTDT_r276_qualifier,3.20.0.OTDT_r276_qualifier]'/>
</to>
</change>
</changes>
<lifeCycle>
<required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.feature.group' range='[3.18.200.v20191101-0300,3.18.200.v20191101-0300]' greedy='false'/>
</lifeCycle>
The "lifeCycle" part references the initially patched feature, which seems correct.
I suspect that something else in OTDT build chain erroneously alter the default metadata that seem correct.
(In reply to Mickael Istria from comment #21) > So I tried the following Thanks for in-depth investigation. Much appreciated. > I suspect that something else in OTDT build chain erroneously alter the > default metadata that seem correct. You hit it. We have a history of p2-usages that are only possibly by rewriting content.xml. Directly related to my report here is bug 350133, where none less than Pascal Rapicault recommended to re-write the lifeCycle element from requiring a feature to requiring a plugin. Obviously, such use of p2 makes us fragile in the face of seemingly unrelated changes in p2. I only wish there were an official way to achieve the same ... Anyway, after further tweaks to our content.xml-rewriting I have build running past the previous error. |
build: 3.7 I'm seeing this behaviour with 3.7: - create feature patch against specific version (e.g. RCP version that is in the SDK) - export feature patch - look at the metadata, it seems to be matching ANY version of the rcp feature <unit id='org.eclipse.rcp.patch.feature.group' version='1.0.0.201106221102' singleton='false'> <patchScope> <scope> <requires size='1'> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.rcp.feature.group' range='0.0.0'/> </requires> </scope> </patchScope> ...