Community
Participate
Working Groups
Here is a "real world" example of the wrong resolution. The bundle org.hamcrest.core (1.1.0.v20090501071000) has the following Export-Package directive in it's MANIFEST.MF: Export-Package: org.hamcrest;version="1.1.0";core=split;mandatory:=core The bundle org.mockito.core (1.8.5) has the following Import-Package directive: Import-Package: [...],org.hamcrest;version="[1.0,2.0)",[...] Equinox will not allow the dependency of org.mockito.core to be resolved by org.hamcrest.core as the import does not contain the attribute "core=split" (required because of the "mandatory" directive). But p2 happily resolves the requirements of org.mockito.core with org.hamcrest.core. This is a problem when you use p2 to resolve the bundles needed to run a rcp: It comes up with a solution that wont run.
This is a known problem. p2 metadata does not carry all the aspects of the OSGi metadata. To solve this we need to enhance the capability model and make sure the query can work on this. This should be addressed by changes done in the context of https://bugs.eclipse.org/324352. At this point I don't think this work would require any resolver change.
Bug 324352 has been marked as a duplicate of Bug 313553
*** Bug 398886 has been marked as a duplicate of this bug. ***
Related problem: the publisher also ignores the (OSGi-defined) attributes "bundle-symbolic-name" and "bundle-version" -> bug 400194
(In reply to Holger Oehm from comment #0) > Here is a "real world" example of the wrong resolution. FWIW, another real world example I encountered in the wake of fixing Bug 514071: The bundle org.eclipse.m2e.maven.runtime has the following Export-Package directive: org.eclipse.aether;provider=m2e;mandatory:=provider This mandatory attribute has been introduced in 2014 [1] because org.eclipse.m2e.maven.runtime wraps *lots* of bundles and is not really usable by anything else besides other org.eclipse.m2e.* bundles without uses constraint violations (Bug 403243). Now Code Recommenders would like to use the bundle org.apache.maven.resolver.api as provider of package org.eclipse.aether, but p2 installs org.eclipse.m2e.maven.runtime instead -- which Equinox fails to wire Code Recommenders' bundles to because of the mandatory provider=m2e attribute. [1] <https://git.eclipse.org/c/m2e/m2e-core.git/commit/m2e-maven-runtime/org.eclipse.m2e.maven.runtime/pom.xml?id=7e198c6ae5cffbd6fc45e0cb3b54492123d7e2e4>
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This is still relevant and hurting Tycho (bug 403196), even more visible with the new resolver.
Actually, it's a bit more than just "mandatory": p2 ignores properties at all. So a 1st step is to have p2 exposing the properties for import/export and then have the resolver taking those property into account.
(In reply to Mickael Istria from comment #8) > Actually, it's a bit more than just "mandatory": p2 ignores properties at > all. So a 1st step is to have p2 exposing the properties for import/export > and then have the resolver taking those property into account. Can you explain a bit more what "ignores" mean? Did the mean that attributes on packages (or more general manifest headers) are not recorded at all?
(In reply to Christoph Laeubrich from comment #9) > Can you explain a bit more what "ignores" mean? Did the mean that attributes > on packages (or more general manifest headers) are not recorded at all? Right, those attributes are not even published to the p2 metadata and the capability/requirements in content.xml do not show them at all.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
