Does bnd-resolver-maven-plugin have trouble with Bundle-NativeCode?

[reckart]

It seems when I have a dependency on a bundle that contains native libraries, the bnd-resolver-maven-plugin (and also the resolver in the bnd runfile editor in Eclipse) seem to have a problem. E.g.:

[ERROR] Resolution failed. Capabilities satisfying the following requirements could not be found:
    [<<INITIAL>>]
    ....
    [org.xerial.snappy.snappy-java version=1.1.1.3]
      ⇒ osgi.native: (|(&(osgi.native.osname~=win32)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=win32)(osgi.native.processor~=x86))(&(osgi.native.osname~=macosx)(osgi.native.processor~=x86))(&(osgi.native.osname~=macosx)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86))(&(osgi.native.osname~=linux)(osgi.native.processor~=arm))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64le))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparc)))

I'm running on a 64bit Intel Mac, so I guess that the (&(osgi.native.osname~=macosx)(osgi.native.processor~=x86-64)) should match.

I have had the same problem already with two different bundles - one that I tried to build myself but then figured out that javacc appear to be able to loads its native libraries even withtout this OSGI native statement - and now again with an off-the-shelve snappy.

I have tried debugging this in Maven with -X, but I didn't see and more helpful information on what may be going wrong here.

Is this a known issue? If not, any idea how to debug this (without attaching a debugger and step through the code)?

bnd: 6.3.1

[reckart]

Just found this: bndtools/bndtools#1059

Honestly - maybe add this -runsystemcapabilities: ${native_capability} by default?

[reckart]

Or at least add a helpful hint in the error message that this option exists?

[reckart]

Btw. I see that this option was added to some templates. I based by bndrun files off this tutorial: https://github.com/rotty3000/osgi-test-example-mvn

Since there can be many reasons for people not starting off from the templates, I think hinting at the setting in an error message would be helpful.

[rotty3000]

hi @reckart sorry for the omission in the example, I'll try to make it current.

But yeah, it would be nice to improve the error messages. I've long wished for bnd to parse the error messages out of the resolver (it does to some degree) to product some more useful hints such as this one.

[timothyjward]

hi @reckart sorry for the omission in the example, I'll try to make it current.

But yeah, it would be nice to improve the error messages. I've long wished for bnd to parse the error messages out of the resolver (it does to some degree) to product some more useful hints such as this one.

We could issue a general warning if the list from https://docs.osgi.org/javadoc/r6/cmpn/org/osgi/service/resolver/ResolutionException.html#getUnresolvedRequirements() contains a requirement in the osgi.native namespace.
Something like:

By default bnd does not include any platform specific capabilities when resolving. This can cause problems if the resolution has native code dependencies.
If your resolution does have native dependencies then you must add an osgi.native capability for your target platform using runsystemcapabilities. If appropriate you can use the ${native_capability} macro which expands to the native capability of the currently executing platform.

[reckart]

What eventually put me on the track to google for something that produced a link to bndtools/bndtools#1059 was a message in the build that said:

[INFO] --- bnd-resolver-maven-plugin:6.4.0-SNAPSHOT:resolve (resolve-test) @ MY-MODULE ---
[INFO] Resolving /src/.../MY-MODULE/src/test/osgi/test.bndrun:
[INFO] Bnd inferred -runee: JavaSE-1.8

That bnd inferredput me on the track - in particular because I didn't see something that I was also expecting/hoping for like maybe

[INFO] Bnd inferred -runsystemcapabilities: processor=x86_64, platform=macosx

[rotty3000]

Yeah, attribute inference is limited to a very small subset of instructions that have easily assumable values (just 2 to be precise; -runee (the current JDK version) and -runbundles (the current project) ).

However the moment you specify the instruction inference is disabled. It doesn't even consider expansion of values just whether the instruction was used or not. So it's rather simplistic in it's current form. What you are talking about is echo instructions, but which ones? The list is really huge and will very much pollute the output. We'd need a heuristic of some kind... but which ones are the important ones in a given scenario is going to be hard to derive. Anyway, I like the idea in general, but maybe we'd be better served by an instruction that asks to dump all or some specified bit of the configuration... However, I don't know if that solves your problem. I feel the solution here is more inline with what you yourself and @timothyjward mentioned.. better error output :)

[bjhargrave]

@pkriens will investigate ensuring there is a default osgi.native capability in the resolution process.

[pkriens]

Implemented in #5387