Eclipse Community Forums: P2 » p2 resolver hints

Help

Home

Home » Eclipse Projects » P2 » p2 resolver hints - forcing wiring (OSGi)

Show: Today's Messages :: Show Polls :: Message Navigator

p2 resolver hints - forcing wiring (OSGi) [message #996541]

Wed, 02 January 2013 10:26

Peter Taylor

Messages: 5
Registered: January 2013

Junior Member

I have 3 plugins in my product (amongst others):

[1] com.ibm.dfdl.runtime (external)
-> exports package org.google.protobuf
[2] org.jboss.netty (external)
<- imports package org.google.protobuf
[3] com.greenhat.vie.comms (internal)
-> exports package org.google.protobuf

I need to work out how to FORCE [2] to wire org.google.protobuf to [3]... since it intermittently wires [2] to [1] which breaks the product due to a 'package use conflict'. Note: I can only change my bundle, [3] since the others are third party.

The OSGi Spec says:

OSGi.core-4.3.0.pdf

3.8 Resolving Process

The following list defines the preferences, if multiple choices are possible, in order of decreasing priority:
• A resolved exporter must be preferred over an unresolved exporter.
• An exporter with a higher version is preferred over an exporter with a lower version.
• An exporter with a lower bundle ID is preferred over a bundle with a higher ID.

So I guess I'm asking how can I force 'com.greenhat.vie.comms' to resolve BEFORE 'com.ibm.dfdl.runtime'

Suggestions?

Thanks,

Peter T

[Updated on: Wed, 02 January 2013 15:59]

Report message to a moderator

Re: p2 resolver hints - forcing wiring (OSGi) [message #1027794 is a reply to message #996541]

Wed, 27 March 2013 12:24

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

Can you post the 'package use conflict' message? I am having a hard time understanding the order of installation. It seems you must have com.ibm.dfdl.runtime installed (and resolved) and then you are installing a set of features that pull in org.jboss.netty and com.greenhat.vie.comms. In this case the framework would wire org.jboss.netty to the export of org.google.protobuf from com.ibm.dfdl.runtime because it is from a bundle already resolved.

Is it possible to change [3] com.greenhat.vie.comms to export AND import the org.google.protobuf package:

Export-Package: org.google.protobuf; version="2.4.1"
Import-Package: org.google.protobuf; version="[2.4, 2.5)"

This way we can allow [3] to get wired to [1] and have its export substituted so that all can use the same version of the org.google.protobuf package.

Tom

P.S. This has nothing to do with P2 but rather is a framework runtime resolution issue.

Report message to a moderator

Re: p2 resolver hints - forcing wiring (OSGi) [message #1027806 is a reply to message #1027794]

Wed, 27 March 2013 12:37

Peter Taylor

Messages: 5
Registered: January 2013

Junior Member

'framework runtime resolution issue' i.e. should be an equinox forum post?

yes, I have added a import package statement to workaround the issue for now. But what if I needed version 2.4.1 rather than 2.4.0 to be 'resolved'?

This is an example error I get:
!SUBENTRY 2 com.ghc.ghTester 2 0 2013-03-22 14:52:24.613
!MESSAGE Package uses conflict: Require-Bundle: org.jboss.netty; bundle-version="0.0.0"

can I configure p2 in some way to change the install order on the bundles?
I'm having a hard time understanding this page:
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_customizing_metadata.html

Report message to a moderator

Re: p2 resolver hints - forcing wiring (OSGi) [message #1027844 is a reply to message #1027806]

Wed, 27 March 2013 13:44

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

If I understand correctly, your scenario has com.ibm.dfdl.runtime already installed and later you are installing a new set of features/bundles into the installation. So here p2 cannot control the install order because it is too late, com.ibm.dfdl.runtime has already been installed into the runtime.

What happens if you start with -clean? I imagine that would cause the correct wiring since it would force a re-install of all the configured bundles and a full resolution.

!SUBENTRY 2 com.ghc.ghTester 2 0 2013-03-22 14:52:24.613
!MESSAGE Package uses conflict: Require-Bundle: org.jboss.netty; bundle-version="0.0.0"

Do you have control over com.ghc.ghTester? If so can you have it use Import-Package to get the packages from the org.jboss.netty bundle? That may give the framework more choices to be able to pick a valid solution for a consisten class space.

Report message to a moderator

Re: p2 resolver hints - forcing wiring (OSGi) [message #1027889 is a reply to message #1027844]

Wed, 27 March 2013 14:51

Peter Taylor

Messages: 5
Registered: January 2013

Junior Member

it would appear that DFDL is installed first yes - but not from the metadata we are producing. we are either upgrading the product, or doing a product build. we aren't explicitly doing anything with DFDL before our plugins.

I may try declaring in the built feature that we require dfdl. may be that would help *something* install/resolve the plugins in one go.

'-clean' does solve the problem as a workaround. yes. although I can't specify that in the build so butcher manifests instead.

com.ghc.ghTester bundle (which we control) has a require bundle org.jboss.netty already.

I'm a bit unclear why the resolver issues this message if it can be 'fixed' by calling '-clean', I'd have expected the resolver to 'try harder' before erroring. If this were safe I'd call '-clean' during product install but I believe '-clean' does more than just re-evaluate bundle dependencies, i.e. removes additionally installed bundles.

Report message to a moderator

Re: p2 resolver hints - forcing wiring (OSGi) [message #1028091 is a reply to message #1027889]

Wed, 27 March 2013 20:31

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

The framework resolver cannot try harder because there are a set of bundles already installed and resolved. The framework cannot change the resolution decisions for these already resolved bundles when the new set of bundles is installed. The issue is the previous decision that is persisted affects the ability to find a possible solution when you install the new set of bundles and are trying to resolve them against the current class space.

You are correct that -clean starts from a clean slate and causes p2 to reinstall all the configured bundles again and that results in all the configured bundles to be resolved at the same time instead of in stages as your scenario has when installing into an existing install (or doing an upgrade).

Report message to a moderator

Re: p2 resolver hints - forcing wiring (OSGi) [message #1028459 is a reply to message #1028091]

Thu, 28 March 2013 09:26

Peter Taylor

Messages: 5
Registered: January 2013

Junior Member

So I guess the answer is whatever is installing / upgrading the bundles needs to do so less incrementally? since I think you are telling me there is nothing that equinox can do about my problem, and no way I can tell it to safely re-resolve all bundles i.e. -safeclean. so it's a p2 problem or whatever is calling p2.

Report message to a moderator

Re: p2 resolver hints - forcing wiring (OSGi) [message #1032056 is a reply to message #1028459]

Tue, 02 April 2013 14:13

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

The Equinox framework should not do this re-resolve auto-magically. p2 could have some way to force it to re-refresh everything on restart, but it is difficult to have a consistent policy to do this without causing unexpected refreshes of the system.

Report message to a moderator

Previous Topic:	Installed plugin/features in ~/.eclipse
Next Topic:	content.xml vs. artifacts.xml

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Jan 03 04:09:49 GMT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter