Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 360659

Summary: [metadata][planner] p2 resolves Import-Package requirements incorrectly (ignores mandatory attributes)
Product: [Eclipse Project] Equinox Reporter: Holger Oehm <holger.oehm>
Component: p2Assignee: P2 Inbox <equinox.p2-inbox>
Status: REOPENED --- QA Contact:
Severity: normal    
Priority: P3 CC: akurtakov, alex.blewitt, beyhan.veliev, cvgaviao, goulwen.lefur, guillez, gunnar, laeubi, mat.booth, mistria, mn, pascal, petar.petrov, pwebster, reto.urfer, sebastian.ratz, sewe, steven.soloff, t-oberlies
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard: stalebug
Bug Depends on:    
Bug Blocks: 403196, 471906, 572177, 578054    

Description Holger Oehm CLA 2011-10-12 08:27:46 EDT
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.
Comment 1 Pascal Rapicault CLA 2011-10-12 22:19:57 EDT
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.
Comment 2 Holger Oehm CLA 2012-10-08 08:00:30 EDT
Bug 324352 has been marked as a duplicate of Bug 313553
Comment 3 Tobias Oberlies CLA 2013-01-24 02:50:14 EST
*** Bug 398886 has been marked as a duplicate of this bug. ***
Comment 4 Tobias Oberlies CLA 2013-02-07 05:34:38 EST
Related problem: the publisher also ignores the (OSGi-defined) attributes "bundle-symbolic-name" and "bundle-version" -> bug 400194
Comment 5 Andreas Sewe CLA 2017-03-29 04:21:29 EDT
(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>
Comment 6 Eclipse Genie CLA 2019-11-11 08:29:34 EST
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.
Comment 7 Mickael Istria CLA 2021-02-08 05:01:29 EST
This is still relevant and hurting Tycho (bug 403196), even more visible with the new resolver.
Comment 8 Mickael Istria CLA 2021-03-24 05:56:37 EDT
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.
Comment 9 Christoph Laeubrich CLA 2022-01-05 09:05:28 EST
(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?
Comment 10 Mickael Istria CLA 2022-01-05 09:12:11 EST
(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.