How to troubleshoot bndtools org.osgi.service.resolver.ResolutionException?

[Brian Brooks]

Would someone be able to guide me on troubleshooting a bndtools resolve error?  I don't see any errors in the Eclipse console, nor in the Eclipse error log.  I'm not sure how to get more debug info.

Note that this is a cross-post.  Previously, I posted this here http://enroute.osgi.org/forum.html#comment-2551920049.

I'm trying to get enroute running on Makewave Knopflerfish.  I have a bndrun with all the Knopferlfish bundles I typically use over the last 5 years to run non-enroute apps.  This set of bundles works fine when running outside of bndtools launched via Knopflerfish's framework.jar.  Resolving worked fine with the bndrun generated by the enroute templates somehow my adjustments to launch on Knopflerfish are causing this resolve failure.

The error is bndtools resolve error is:

org.osgi.service.resolver.ResolutionException: Unable to resolve <<INITIAL>> version=null: missing requirement org.bnd4.eval.application 

->  Unable to resolve org.bnd4.eval.application version=1.0.0.201603042149: missing requirement org.bnd4.eval.api; version=[1.0.0,2.0.0) 

->  Unable to resolve org.bnd4.eval.api version=1.0.0.201603042149: missing requirement false]]

My bndrun is

Bundle-Version: 1.0.0.${tstamp}

Bundle-SymbolicName: org.bnd4.eval.application.launch

JPM-Command: eval

-runfw: org.knopflerfish.framework;version='[7.2.0,7.2.0]'

-runrequires: osgi.identity;filter:='(osgi.identity=org.bnd4.eval.application)'

-runbundles: \

org.apache.felix.http.api;version='[3.0.0,3.0.1)',\

org.apache.felix.http.jetty;version='[3.1.0,3.1.1)',\

org.apache.felix.http.servlet-api;version='[1.1.2,1.1.3)',\

org.bnd4.eval.application;version=snapshot,\

org.bnd4.eval.provider;version=snapshot,\

org.eclipse.equinox.coordinator;version='[1.3.100,1.3.101)',\

org.eclipse.equinox.metatype;version='[1.4.100,1.4.101)',\

org.osgi.service.metatype;version='[1.3.0,1.3.1)',\

osgi.enroute.configurer.simple.provider;version='[1.2.2,1.2.3)',\

osgi.enroute.dto.bndlib.provider;version='[1.0.0,1.0.1)',\

osgi.enroute.executor.simple.provider;version='[1.0.0,1.0.1)',\

osgi.enroute.google.angular.webresource;version='[1.4.4,1.4.5)',\

osgi.enroute.logger.simple.provider;version='[1.1.1,1.1.2)',\

osgi.enroute.rest.simple.provider;version='[2.0.2,2.0.3)',\

osgi.enroute.twitter.bootstrap.webresource;version='[3.3.5,3.3.6)',\

osgi.enroute.web.simple.provider;version='[1.3.3,1.3.4)',\

org.knopflerfish.bundle.cm_cmd-IMPL,\

org.knopflerfish.bundle.console,\

org.knopflerfish.bundle.consoletelnet-IMPL,\

org.knopflerfish.bundle.frameworkcommands-IMPL,\

org.knopflerfish.bundle.kxml-LIB,\

org.knopflerfish.bundle.logcommands-IMPL,\

org.knopflerfish.bundle.sslj2sp-IMPL,\

org.knopflerfish.bundle.util-LIB,\

org.knopflerfish.framework,\

org.knopflerfish.bundle.cm,\

org.knopflerfish.bundle.component,\

org.knopflerfish.bundle.event,\

org.knopflerfish.log

-runee: JavaSE-1.8

[Peter Kriens]

The resolve error indicates that the only exporter is the API project but that this project says it should not resolve because in enRoute we highly recommend to include the API package in the provider so a resolution does not just consist of APIs without implementations. If you look in your bnd.bnd file in the org.bnd4.eval project then you'll see the following lines:

Require-Capability: \
compile-only

This is a requirement that cannot be resolved. Adding the package to the provider will then make the provider the preferred exporter.

This model (exporting the API from the provider) is explained extensively in the Base Tutorial (seehttp://enroute.osgi.org/tutori... and in for example http://bnd.bndtools.org/chapte....

You should there have some org.bnd4.eval.provider bundle that provides the implementation and this should export the API. Exporting it is simple, just drag the package and drop it on the Contents Export list of the provider's bnd.bnd file. See the Base tutorial for details.

That said, in the OSGi we now have implementation capabilities and the next enRoute setup will use those. It is slightly cleaner but also a bit less practical. For now, just export the API from the provider it is the last amount of trouble.

I’ve created a FAQ and added this: http://enroute.osgi.org/book/900-faq.html

Kind regards,

Peter Kriens

> --
> You received this message because you are subscribed to the Google Groups "bndtools-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Brian Brooks]

Hi Peter,

Strange, my .provider already exports the .api as prescribed in the enroute tutorials.  See the .provider's bnd.bnd below...

org.bnd4.eval.provider/bnd.bnd:

Bundle-Version: 1.0.0.${tstamp}

Bundle-Description: org.bnd4.eval.provider

Private-Package: \

org.bnd4.eval.provider

--snip--

-buildpath: \

osgi.enroute.base.api;version=1.0,\

org.bnd4.eval.api;version=latest

--snip--

-runrequires: \

osgi.identity;filter:='(osgi.identity=org.bnd4.eval.provider)',\

osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)'

-runbundles: \

org.apache.felix.configadmin;version='[1.8.6,1.8.7)',\

org.apache.felix.gogo.runtime;version='[0.16.2,0.16.3)',\

--snip--

Export-Package: org.bnd4.eval.api

On Saturday, March 5, 2016 at 6:14:15 AM UTC-5, pkriens wrote:

--snip

You should there have some org.bnd4.eval.provider bundle that provides the implementation and this should export the API. Exporting it is simple, just drag the package and drop it on the Contents Export list of the provider's bnd.bnd file. See the Base tutorial for details.

That said, in the OSGi we now have implementation capabilities and the next enRoute setup will use those. It is slightly cleaner but also a bit less practical. For now, just export the API from the provider it is the last amount of trouble.

--snip-- 

[Peter Kriens]

Ok, try then to resolve ONLY the provider (i.e. is the only requirement) and see what it says. Likely the provider has a problem. You could also add the API bundle the blacklist in your bndrun file.

-runblacklist.eval: \

osgi.identity;filter:=‘(osgi.identity=org.bnd4.eval.provider)

The resolver will then probably provide the next thing it cannot resolve. Which unfortunately is often quite logical and simple :-(

The resolver is pretty bad in telling what the culprit is. The reason is that it uses back-tracking. So the diagnostics are basically the last thing that was tried. 

If it still does not work, you could share your project and I can take a look.

Kind regards,

Peter Kriens

[Brian Brooks]

Great!  Adding the api blacklist to knop.bndrun

-runblacklist.eval: \

osgi.identity;filter:='(osgi.identity=org.bnd4.eval.api)'

permitted me to see the underlying error...

org.osgi.service.resolver.ResolutionException: Unable to resolve <<INITIAL>> version=null: missing requirement org.bnd4.eval.application 

->  Unable to resolve org.bnd4.eval.application version=1.0.0.201603051452: missing requirement org.bnd4.eval.api; version=[1.0.0,1.1.0) 

->  Unable to resolve org.bnd4.eval.provider version=1.0.0.201603051447: missing requirement &(osgi.extender=osgi.component)(version=[1.0.0,2.0.0)) 

->  Unable to resolve org.apache.felix.scr version=2.0.0: missing requirement org.osgi.dto; version=[1.0.0,2.0.0)]]]

Somehow org.apache.felix.scr has worked its way back into the launch bundles.  I guess it's through the provider bnd.bnd because I replaced it with org.knopflerfish.bundle.component in my org.bnd4.eval.applicatin's knop.bndrun file.

I guess this means I need to update org.bnd4.eval.provider bnd.bnd and replace all some of the equinox/felix bundles with their corresponding knopflerfish bundles.

Brian

[Peter Kriens]

One of the hidden under appreciated gems of enRoute is the curated distro. As you find out, this is non trivial. If you wan to make, create a new distro. You can verify the distro be resolving it against the [guard][1]. The guard requires EVERY capability in OSGi enRoute 1.0. If that resolves, you should never have to chase these kind of bugs.

You should then create a replacement for cnf/ext/enroute-distro.bnd. (call it enroute-knopflerfish.bnd) In this file you can [augment][2] the repository members because generally not all bundles are properly done.

If you make an indexed repo with the bundles + this file enroute-knopflerfish.bnd and you’re willing to share it then I’d love to have it on the OSGi web site.

 

Kind regards,

Peter Kriens

[1]: https://github.com/osgi/osgi.enroute/tree/master/osgi.enroute.base.guard

[Brian Brooks]

Thanks for pointing out the [guard][1].  I also see the -augment lines in enroute-distro.bnd [2].

I'm planning to work this week on getting enroute to run on Knopflerfish.  If successful, I'm more than willing to share the fruits of the labor.  We're building our 2nd OSGi-based app which is a port of a old C application that is sometimes ran in embedded hardware environments.  Therefore, Knopflerfish seemed like the right choice because of Makewave's focus on embedded deployments.

This app is our second OSGi-based app.  The first app runs on Knopflerfish and has been built over the last 5 years;  it now has about 30 bundles.

From your post, I understand that you're suggesting an approach of creating a new Eclipse bndtools workspace in which:

1. cnf/ext/enroute-distro.bnd is replaced with a new cnf/ext/enroute-knopflerfish.bnd.

2. Setup a FixedIndexedRepo in enroute-knopflerfish.bnd to house Knopflerfish bundles.

3. import the [guard] bundle.

Then use this workspace to iteratively add the Knopflerfish bundles to the FixedIndexRepo which satisfy the [guard] bundle's requirements.

I must admit that the 7500 line indexed repo [3] for enroute-distro.bnd is intimidating; it definitely leaves me questioning whether pursuing an enroute-knopflerifsh.bnd is worth it.  I wonder if felix or equinox would run just as well as knopflerfish in a low-memory / flash memory environment...

[1]: https://github.com/osgi/osgi.enroute/tree/master/osgi.enroute.base.guard

[2]: http://bnd.bndtools.org/instructions/augment.html

[3]: https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/index.xml

Brian

[Peter Kriens]

How’s it going? :-)

Kind regards,

Peter Kriens

[Brian Brooks]

On March 23, pkriens wrote:

> How’s it going? :-)

Thanks for checking... we ended up lowering our expectations.

Makewave Knopflerfish support responded to our inquiry about R6 / enroute support.  They're planning to work on R6 / enroute support and modernizing their toolchain from "Knopflerfish/Ant/Eclipse" to "Knopflerfish/gradle/bndtools" over the next few weeks.

Given that information, schedule pressures, and the fact that we don't absolutely yet need the features afforded by enroute; we decided to just mostly stick with the older non-enroute bndtools templates running on Knopflerfish 5.x for now.  We are still using the enroute junit bundle.  If we want to use the enroute .provider or .test templates, we usually edit -buildpath in the default bnd.bnd...

-buildpath: \

osgi.annotation;version=6.0.1,\

osgi.core;version=5.0,\

osgi.cmpn;version=5.0,\

We did create a knopflerfish-r5.bnd suitable for dropping into cnf/ext.  Here it is (I don't know if all the runblacklist bundles are really needed nor if the runsystemcapabilities line is needed):

# cnf/ext/knopflerfish-r5.bnd

#

# Knopflerfish 5.x / OSGi R5 Support 

#

-runfw: org.knopflerfish.framework;version='[7.2.0,7.2.0]'

-runblacklist.enroute: \

osgi.identity;filter:='(osgi.identity=osgi.enroute.base.api)', \

osgi.identity;filter:='(osgi.identity=osgi.cmpn)', \

osgi.identity;filter:='(osgi.identity=osgi.core)', \

osgi.identity;filter:='(osgi.identity=biz.aQute.junit)', \

osgi.identity;filter:='(osgi.identity=biz.aQute.launcher)', \

osgi.identity;filter:='(osgi.identity=biz.aQute.remote.launcher)'

-runsystemcapabilities.dflt: ${native_capability}

-augment.kn_scr: \

org.knopflerfish.bundle.component; \

capability:="osgi.extender;osgi.extender='osgi.component';version:Version='1.2.1'"

-augment.kn_ht: \

    org.knopflerfish.bundle.http; \

    capability:="osgi.implementation;osgi.implementation=org.osgi.service.http"

-augment.kn_lo: \

    org.knopflerfish.log; \

    capability:="osgi.service;objectClass=org.osgi.service.log.LogService;effective:=active, \

        osgi.implementation;osgi.implementation=osgi.log"

We're also relying on a FixedIndexedRepo populated with these Knopflerfish 5.x bundles...

org.knopflerfish.framework

org.knopflerfish.log

org.knopflerfish.bundle.component

org.knopflerfish.bundle.event

org.knopflerfish.bundle.cm

org.knopflerfish.bundle.kxml-LIB

Our full .application bndrun looks like...

-runblacklist.jmcomm: \

osgi.identity;filter:='(osgi.identity=ourorg.ourapp.api)',\

osgi.identity;filter:='(osgi.identity=osgi.residential)',\

osgi.identity;filter:='(osgi.identity=osgi.enterprise)',\

osgi.identity;filter:='(osgi.identity=osgi.compendium)'

 

-runrequires: \

osgi.identity;filter:='(&(osgi.identity=org.knopflerfish.bundle.event)(version>=4.0.1))',\

osgi.identity;filter:='(&(osgi.identity=org.knopflerfish.bundle.component)(version>=5.0.3))',\

osgi.identity;filter:='(&(osgi.identity=org.knopflerfish.bundle.cm)(version>=5.0.1))',\

osgi.identity;filter:='(&(osgi.identity=org.knopflerfish.log)(version>=5.0.0))',\

osgi.identity;filter:='(&(osgi.identity=org.apache.felix.gogo.command)(version>=0.14.0)(version<=0.14.1))',\

osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\

osgi.identity;filter:='(&(osgi.identity=org.apache.felix.gogo.runtime)(version>=0.16.2)(version<=0.16.3))',\

osgi.identity;filter:='(osgi.identity=ourorg.ourapp.b1)',\

osgi.identity;filter:='(osgi.identity=ourorg.ourapp.b2)',\

osgi.identity;filter:='(osgi.identity=ourorg.ourapp.b3')

-runbundles: \

ch.qos.logback.classic;version='[1.1.6,1.1.7)',\

ch.qos.logback.core;version='[1.1.6,1.1.7)',\

com.fasterxml.jackson.core.jackson-annotations;version='[2.6.2,2.6.3)',\

com.fasterxml.jackson.core.jackson-core;version='[2.6.2,2.6.3)',\

com.fasterxml.jackson.core.jackson-databind;version='[2.6.2,2.6.3)',\

ourorg.ourapp.b1;version=snapshot,\

ourorg.ourapp.b2;version=snapshot,\

ourorg.ourapp.b3;version=snapshot,\

org.apache.felix.gogo.command;version='[0.14.0,0.14.1)',\

org.apache.felix.gogo.runtime;version='[0.16.2,0.16.3)',\

org.apache.felix.gogo.shell;version='[0.10.0,0.10.1)',\

org.knopflerfish.bundle.cm;version='[5.0.1,5.0.2)',\

org.knopflerfish.bundle.component;version='[5.0.3,5.0.4)',\

org.knopflerfish.bundle.event;version='[4.0.1,4.0.2)',\

org.knopflerfish.bundle.kxml-LIB;version='[2.3.0,2.3.1)',\

org.knopflerfish.log;version='[5.0.0,5.0.1)',\

slf4j.api;version='[1.7.18,1.7.19)'

-runproperties: \

    org.knopflerfish.framework.debug.errors=true,\

    org.knopflerfish.log.level=error,\

    org.knopflerfish.log.out=true,\

    org.knopflerfish.log.grabio=true,\

    org.knopflerfish.log.file=false,\

    org.knopflerfish.log.memory.size=250,\

    org.knopflerfish.log.file.dir=.

#    ,\

#    org.knopflerfish.consoletelnet.user=admin,\

#    org.knopflerfish.consoletelnet.pwd=admin,\

#    org.knopflerfish.consoletelnet.port=2232,\

#    \

#    ds.loglevel=debug,\

#    ds.showtrace=true,\

#    ds.showerrors=true

Brian