Community
Participate
Working Groups
Bug 528387 introduced a new version of the p2 metadata (1.2.0). This broke some update scenarios, in which one-and-the same bundle (and version) is part of multiple repositories whose p2 metadata (content.xml) differes in the version (1.1.0 vs 1.2.0). Consider this scenario: Local repository (e.g. a 2018-12 installation): <unit id='org.eclipse.equinox.event' version='1.5.0.v20181008-1938' singleton='false'> ... <provides size='10'> ... <provided namespace='osgi.service' name='org.eclipse.equinox.event_1.5.0.v20181008-1938-1' version='0.0.0'/> <-- 1.1.0 metadata, the 1.2.0 metadata additional properties are not yet known here ... </provides> ... </unit> Remote update site (e.g. 2019-03 repository): <unit id='org.eclipse.equinox.event' version='1.5.0.v20181008-1938' singleton='false' generation='2'> ... <provides size='10'> ... <provided namespace='osgi.service' name='org.eclipse.equinox.event_1.5.0.v20181008-1938-1' version='0.0.0'> <properties size='1'> <property name='objectClass' value='org.osgi.service.event.EventAdmin' type='List'/> </properties> </provided> ... </provides> ... </unit> <unit id='org.eclipse.e4.ui.workbench' version='1.9.0.v20190220-1356' generation='2'> ... <requires size='27'> <requiredProperties namespace='osgi.service' match='(objectClass=org.osgi.service.event.EventAdmin)'/> <--- 1.2.0 metadata ... </requires> </unit> Installing org.eclipse.e4.ui.workbench from the update site is now impossible, because the identical artifact org.eclipse.equinox.event already exists in the same version locally, but the local metadata is version 1.1.0 and does not yet expose the "objectClass" property. The remote "variant" of that same bundle does not help, because it is not even considered: SimplePlanner.gatherAvailableInstallableUnits() uses pluginId+Version as a unique key and the "remote variant" is simply ignored. The attempt to install new software fails with: "requires 'osgi.service; (objectClass=org.osgi.service.event.EventAdmin)' but it could not be found". This can be observed already in the wild: https://www.eclipse.org/forums/index.php/t/1098132/ https://www.eclipse.org/lists/cross-project-issues-dev/msg16530.html I was hoping that a local 'eclipse -clean' would help here, expecting the local p2 metadata to get re-built from the actual bundles' MANIFEST.MF, but this does not help at all.
I think we need to bump the version (+0.0.100) of such bundles to make sure that new metadata lead to creation of a new version.
Bumping the bundle version could work, but feels like a hack/workaround. The MANIFEST.MF of the bundle already declares all those properties and it will not change. Does it actually solve the problem in all scenarios? What is someone includes the bundle with the bumped version in a custom update site, and builds that update site with an old Tycho (metadata 1.1.0)? Chances are *that* bundle will somehow end up in a local eclipse installation and the local metadata is again out-of-date. I think the problem lies much deeper: The fact that the update mechanism relies on *p2 metadata* at all, instead of some sort of (to put it crudely) "a concatenation of MANIFEST.MF". That way, the the relevant dependencies could be extracted by the updater for both local and remote repositories on-demand, and in exactly the way that would be compatible across local and remote repositories.
Yes, I've been bitten by this problem too.
(In reply to Sebastian Ratz from comment #2) > Bumping the bundle version could work, but feels like a hack/workaround. The thing with p2 is that metadata are supposed to be generated only once (by the build producer) and be always reused. The fact that the same bundle in same version can have 2 different set of metadata is a problem, just like if it had different .class files. So while it's not perfect, it's actually a good practice to generate a new version when we produce new metadata. > What is someone includes the bundle with the bumped version in a custom > update site, and builds that update site with an old Tycho (metadata 1.1.0)? > Chances are *that* bundle will somehow end up in a local eclipse > installation and the local metadata is again out-of-date. That's a good question. I hope in this case, a build failure would happen to force usage of a newer Tycho or copy the metadata "as it" without shrinking the parts of metadata it doesn't understand, but you may be right that this case might be tolerated erroneously. Can you please verify this scenario? > The MANIFEST.MF of the bundle already declares all those properties and it > will not change. > > The MANIFEST.MF of the bundle already declares all those properties and it > will not change. > I think the problem lies much deeper: The fact that the update mechanism > relies on *p2 metadata* at all, instead of some sort of (to put it crudely) > "a concatenation of MANIFEST.MF". That way, the the relevant dependencies > could be extracted by the updater for both local and remote repositories > on-demand, and in exactly the way that would be compatible across local and > remote repositories. Ok. You're starting to advocate for an almost rewrite of p2 allowing polyglot metadata and using directly MANIFEST.MF as one metadata source for the bundle, aren't you? ;) That's a good idea, but a huge effort, beyond what I have the impression our community is able to provide at the moment.
(In reply to Mickael Istria from comment #4) > (In reply to Sebastian Ratz from comment #2) > > Bumping the bundle version could work, but feels like a hack/workaround. > > The thing with p2 is that metadata are supposed to be generated only once > (by the build producer) and be always reused. The fact that the same bundle > in same version can have 2 different set of metadata is a problem, just like > if it had different .class files. > So while it's not perfect, it's actually a good practice to generate a new > version when we produce new metadata. This was actually done correctly for org.eclipse.equinox.event in bug 416047. But at that point metadata format 1.2.0 didn't even exist, yet. The discrepancy between MANIFEST.MF metadata and p2 metadata is the problem here: As soon as metadata format 1.2.0 was introduced, the versions of all bundles that included a directive not previously exposed in the p2 metadata format. But such version bumps would have been completely out-of-place / backwards, because nothing would have changed inside the bundle itself. > > What is someone includes the bundle with the bumped version in a custom > > update site, and builds that update site with an old Tycho (metadata 1.1.0)? > > Chances are *that* bundle will somehow end up in a local eclipse > > installation and the local metadata is again out-of-date. > > That's a good question. I hope in this case, a build failure would happen to > force usage of a newer Tycho or copy the metadata "as it" without shrinking > the parts of metadata it doesn't understand, but you may be right that this > case might be tolerated erroneously. > Can you please verify this scenario? The problem would still arise. I am not sure if something like "enfore-tycho-version" would even work. How would such a check work? As stated above, the introduction of Provide-Capability: for equinox.event was done in 2016, way before the metadata format 1.2.0 was even introduced. I think such a "enforce-tycho-version" could only make sense in a feature/product build configuration. > > The MANIFEST.MF of the bundle already declares all those properties and it > > will not change. > > > The MANIFEST.MF of the bundle already declares all those properties and it > > will not change. > > > I think the problem lies much deeper: The fact that the update mechanism > > relies on *p2 metadata* at all, instead of some sort of (to put it crudely) > > "a concatenation of MANIFEST.MF". That way, the the relevant dependencies > > could be extracted by the updater for both local and remote repositories > > on-demand, and in exactly the way that would be compatible across local and > > remote repositories. > > Ok. > You're starting to advocate for an almost rewrite of p2 allowing polyglot > metadata and using directly MANIFEST.MF as one metadata source for the > bundle, aren't you? ;) :) > That's a good idea, but a huge effort, beyond what I have the impression our > community is able to provide at the moment. I agree. But having given this some more thought I am out of concrete ideas on how to resolve this / prevent the same thing happening again in the future -- or even resolve this for our own internal tools. As a workaround, we have now built our 2019-03 update site for our product also with an old Tycho version, such that old 1.1.0 p2 metadata data is generated which then is compatible with the existing installations on our client's computers. And we don't see any way how we could make a switch to a new Tycho / 1.2.0 p2 metadata without telling all clients to throw away their installation and replace it with a whole new distribution :/ Side note: For now, org.eclipse.equinox.event seems to be only bundle I found that made use of an osgi.service capability like this. But this could potentially affect many more in other RCP products.
Does anyone see a way out of this? An artificial version bump of 'org.eclipse.equinox.event' would probably help us here, but it feels wrong.
(In reply to Sebastian Ratz from comment #6) > Does anyone see a way out of this? > > An artificial version bump of 'org.eclipse.equinox.event' would probably > help us here, but it feels wrong. I'm not sure on all the details, but we can easily bump the event version for now so as not to break the next release.
New Gerrit change created: https://git.eclipse.org/r/142927
Gerrit change https://git.eclipse.org/r/142927 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=cf7d35636ae39be22eb6799caaa30c0cf8ac91a4
I think this should be marked as resolved fixed.
