I need to work out how to FORCE  to wire org.google.protobuf to ... since it intermittently wires  to  which breaks the product due to a 'package use conflict'. Note: I can only change my bundle,  since the others are third party.
The OSGi Spec says:
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'
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  com.greenhat.vie.comms to export AND import the org.google.protobuf package:
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.
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.
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.
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).
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.
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.