Understanding Unresolved Requirements

[Edu García]

Hello.

I've added a few dependencies to a test project, but I don't understand the output of the Resolve requirements popup.

For example, when adding javax.activation to my project and clicking on resolve, this is what I get:

Resolution failed 

 

Processing errors: OK (I always get OK when resolution fails, and double clicking doesn't show anything) 

 

Unresolved Requirements:
(symbolicname=javax.activation) «initial»
(&(package=javax.activation)) javax.mail.glassfish/1.4.1.v201005082020
(&(symbolicname=system.bundle)) javax.activation/1.1.0.v201105071233

 Why am I getting those? What does it means? I haven't added the javax.mail.glassfish package to the list. If I add it, this is what I get instead:

Resolution failed 

 

Processing errors: OK (I always get OK when resolution fails, and double clicking doesn't show anything)  

 

Unresolved Requirements: 
(symbolicname=javax.mail.glassfish) «initial»
(symbolicname=javax.activation) «initial»
(&(package=javax.activation)) javax.mail.glassfish/1.4.1.v201005082020
(&(symbolicname=system.bundle)) javax.activation/1.1.0.v201105071233 

I don't understand it at all :)

Could anyone explain a bit?

Thanks a lot in advance :)

[Neil Bartlett]

First, note that the resolution failure reporting in the next version of Bndtools is going to be a LOT better... you could check this out of GitHub if you're feeling brave ;-)

In the first case, I'm really not sure why the javax.mail.glassfish bundle is being added to the requirements. Are you absolutely sure that the Run Requirements list does not contain this bundle?

The root of the problem though is that bundle javax.activation has a Require-Bundle dependency on "system.bundle". There is a bug in the Felix resolver in this area: "system.bundle" is an alias for the OSGi Framework, which in reality will have the symbolic name of "org.eclipse.osgi" or "org.apache.felix.framework" etc, depending on which specific OSGi framework you choose. The resolver should recognise the alias as a special case.

The following bug in the Bndtools issue tracker is tracking the issue: https://github.com/bndtools/bndtools/issues/new

Since that issue was first raised, we actually are using a forked version of the Felix resolver in Bndtools, so the problem is fixed, but unfortunately not yet in the released Bndtools. In the meantime I'm not aware of any good workaround other than patching the javax.activation bundle so that it depends on a specific framework BSN rather than the system.bundle alias. Yes this sucks... sorry.

Neil

Edu García

24 May 2012 08:58

[Edu García]

Thanks for your fast response :)

The Run Requirements was totally empty, except for those requirements. I've been trying to add a lot of jars for two days now, and finally I decided to remove everything and start with those that gave me problems in the past, so maybe it's some cache issues or whatever. In the end, I've decided to avoid Run Requirements for now, and add directly everything on Run Bundles, check errors on gogo and add missing bundles. At least, I can work that way.

Another issue I have is the problem with projects not being near /cnf folder, as we have a big Perforce tree with lots of projects, and cannot really move those, so I'm getting lots of errors if I dare touching those projects :) Don't know if it has to do with nothing, but just in case.

I'll try to use the new GitHub version to see the changes :)

Thanks a lot!

On Thursday, May 24, 2012 2:28:38 PM UTC+2, Neil Bartlett wrote:

First, note that the resolution failure reporting in the next version of Bndtools is going to be a LOT better... you could check this out of GitHub if you're feeling brave ;-)

In the first case, I'm really not sure why the javax.mail.glassfish bundle is being added to the requirements. Are you absolutely sure that the Run Requirements list does not contain this bundle?

The root of the problem though is that bundle javax.activation has a Require-Bundle dependency on "system.bundle". There is a bug in the Felix resolver in this area: "system.bundle" is an alias for the OSGi Framework, which in reality will have the symbolic name of "org.eclipse.osgi" or "org.apache.felix.framework" etc, depending on which specific OSGi framework you choose. The resolver should recognise the alias as a special case.

The following bug in the Bndtools issue tracker is tracking the issue: https://github.com/bndtools/bndtools/issues/new

Since that issue was first raised, we actually are using a forked version of the Felix resolver in Bndtools, so the problem is fixed, but unfortunately not yet in the released Bndtools. In the meantime I'm not aware of any good workaround other than patching the javax.activation bundle so that it depends on a specific framework BSN rather than the system.bundle alias. Yes this sucks... sorry.

Neil

[Neil Bartlett]

Hi Edu,

Are you resolving from a bnd.bnd file, or from a .bndrun file? Bear in mind that with a bnd.bnd file, the project's own output bundle(s) are always included implicitly in the resolution results, so this could be the source of the dependency. You may get better results with a .bndrun file, which is independent of any particular project.

By the way, I thought you might be interested to see a screenshot of the new resolution failure diagnostic window in the latest Bndtools version... see attached. To explain this tree a little:

* The top level is always the input requirement from Run Requirements. In this case, I added a requirement on bundle "p2".
* The 2nd level is a bundle that potentially provides that requirement, however...
* The 3rd level down shows the list of unsatisfied requirements from that bundle ("p2"). In this case it is trying to import a package "pkg1".
* The 4th level shows a bundle, "p1", that potentially provides that requirement (i.e. it exports package "pkg2"), however...
* The 5th level shows an unsatisfied requirement from bundle p1: it requires bundle "unicorn". Unicorns don't exist, so this requirement is UNMATCHED, and this is therefore the root cause of the resolution failure.


Regards,
Neil

Edu García

24 May 2012 14:55

Thanks for your fast response :)

The Run Requirements was totally empty, except for those requirements. I've been trying to add a lot of jars for two days now, and finally I decided to remove everything and start with those that gave me problems in the past, so maybe it's some cache issues or whatever. In the end, I've decided to avoid Run Requirements for now, and add directly everything on Run Bundles, check errors on gogo and add missing bundles. At least, I can work that way.

Another issue I have is the problem with projects not being near /cnf folder, as we have a big Perforce tree with lots of projects, and cannot really move those, so I'm getting lots of errors if I dare touching those projects :) Don't know if it has to do with nothing, but just in case.

I'll try to use the new GitHub version to see the changes :)

Thanks a lot!

On Thursday, May 24, 2012 2:28:38 PM UTC+2, Neil Bartlett wrote:

Neil Bartlett

24 May 2012 13:28

First, note that the resolution failure reporting in the next version of Bndtools is going to be a LOT better... you could check this out of GitHub if you're feeling brave ;-)

In the first case, I'm really not sure why the javax.mail.glassfish bundle is being added to the requirements. Are you absolutely sure that the Run Requirements list does not contain this bundle?

The root of the problem though is that bundle javax.activation has a Require-Bundle dependency on "system.bundle". There is a bug in the Felix resolver in this area: "system.bundle" is an alias for the OSGi Framework, which in reality will have the symbolic name of "org.eclipse.osgi" or "org.apache.felix.framework" etc, depending on which specific OSGi framework you choose. The resolver should recognise the alias as a special case.

The following bug in the Bndtools issue tracker is tracking the issue: https://github.com/bndtools/bndtools/issues/new

Since that issue was first raised, we actually are using a forked version of the Felix resolver in Bndtools, so the problem is fixed, but unfortunately not yet in the released Bndtools. In the meantime I'm not aware of any good workaround other than patching the javax.activation bundle so that it depends on a specific framework BSN rather than the system.bundle alias. Yes this sucks... sorry.

Neil

Edu García

24 May 2012 08:58

[Edu García]

Hi Neil,

I'm using a bnd.bnd (I'm a total newbie, and before using this plugin I did all my MANIFEST.MF by hand, and sometimes with the command line bnd :). The project is just a test project, with almost no dependencies whatsoever (I used this tutorial to get up to speed), and later just added declarations to that bnd.bnd to test Jetty 8.1 integration, but when the problems came, I erased every dependency and started with the ones I wrote earlier. Maybe I had something wrong in other part, I'll try again.

The new resolution failure is SO much better (although for the unicorns not existing, you can argue with my little nieces and they can tell you otherwise). Maybe it's the same as now but in tree form. However, I've tried to understand using the same logic some other resolutions I had to do, and still no luck :). I also have to say sometimes Felix itself gets very confused, asking for bundles that are already installed and not seeing them (like geronimo transaction, had lot of problems with that one), etc. So, as you pointed earlier, it could be just Felix bugs.

Anyway, I'll try to use the alpha version (although I tried to use http://bndtools-alpha-updates.s3.amazonaws.com/ but Amazon says it doesn't exist :)

Thanks a lot for your help!