Questions about resolving errors

I have a few questions about resolving errors:

When I get an error report like this:

      ⇒ osgi.identity: (osgi.identity=com.perzeption.valuebundle.persistence.factory.api)
          ⇒ [com.perzeption.valuebundle.persistence.factory.api version=]
              ⇒ compile-only: (compile-only=compile-only)
    [org.apache.commons.commons-io__8 version=2.15.0 type=bnd.synthetic]
      ⇒ (&(>=1.8.0)(!(version>=9.0.0))))
    [com.fasterxml.jackson.core.jackson-databind__8 version=2.13.3 type=bnd.synthetic]
      ⇒ (&(>=1.8.0)(!(version>=9.0.0))))
    [com.fasterxml.jackson.core.jackson-core__6 version=2.13.3 type=bnd.synthetic]
      ⇒ (&(>=1.6.0)(!(version>=9.0.0))))
    [com.perzeption.causetree.element.tree.api version=]
      ⇒ compile-only: (compile-only=compile-only)

What does it mean then:

  1. ⇒ compile-only: (compile-only=compile-only)
    Why is it an error?

  2. In ⇒ (&(>=1.8.0)(!(version>=9.0.0))))
    What does the “!((version>= 9.0.0)) means”?

  3. For [com.fasterxml.jackson.core.jackson-databind__8 version=2.13.3 type=bnd.synthetic]
    What does the “type=bnd.synthetic” means?

  4. And what does the bug report actually want to tell me?

Thank you very much and best regards

Just found this in the manual.

It means that JavaSE must be less than 9.0.0
(&(>=1.8.0)(!(version>=9.0.0)))) is an LDAP Filter expression.
Here is a tool where you can copy-paste such an expression and get an explanation:

Not familiar with this but looks like it has to do something with Multi-Release Jars. I just looked it up in the source code:

Note: Multi Release Jar Support was added in bnd 7.0.0. Which version are you using?
Maybe you could describe a bit more your environment.

I can recommend you the Resolution View of bndtools. e.g. you can click on a bundle in the Repository Browser and it shows you all Requirements and Capabilities of this bundle. It helps to make stuff visible what the Resolver sees and complains about.

Some additions to what @chrisrueger wrote:

Resolution failures come with a bit of stuff, you can usually ignore. You always have to look at the first one, that is one level under [<<INITIAL>>]. I haven’t found out yet, why the resolver produces the rest underneath.
How to read it in generally I have described here some time ago: Data In Motion Consulting

The readability will improve with the release of 7.1, thanks to @chrisrueger.

What does the “type=bnd.synthetic” means?

Yes, this came along with the Multi Release jars. Now a Jar can contain additional classes targeting different java Versions. for the resolver bnd analyses this and provides synthetic versions of such a bundle to the resolver. A Bundle x.y.z, providing code for java 1.8, 9 and 11 will now appear here as x.y.z__8, x.y.z__9 and x.y.z__11 with the corresponding narrow version ranges for their respective Java version.

1 Like

@juergen-albert I find that a great explanation. I proposed a PR where I add your sentence to the manual. Maybe you could have a look and suggest additions. You could also copy the PR and push yourself, since it is your sentence :slight_smile:

First of all, thank you for the quick and helpful answer.

I actually knew point 1, but that couldn’t be the problem.
The problem was that I have 3 main Eclipse workspaces that split my development with over 100 projects (APIs, providers and test projects) into topics.
Also to keep build time as short as possible.
Now I’m having more and more problems that changes sometimes only take effect when Eclipse is restarted.
I merged all the projects together and hey presto, the error was gone!

I didn’t understand point 2 because I’ve been using a Java version higher than 9 for years.
I’ve been using Java21 for a few months now. And if I understand correctly, the version specified isn’t suitable for a Java version 9 or higher, is it?
I’ve also been using this package for a while.
If I have a suitable version, e.g. “__9” or “__11”, why is version “__8” displayed as an error.
That’s confusing!

Point 3 was more interesting because I didn’t know the addition “synthetic” and the appendix “__8”.

The action to imply for you to take is check if there are other of those multirelease versions getting resolved into your -runbundles with different versions and then only keep the one compatible with your java version.

say you have a dependency__8 for Java <= 8, dependency__9 for java <= 9 and dependency__11 for java > 9 and you’re on Java17, you only want to keep dependency__11 in your -runbundles.

Hope this helps others just as confused as I was a few months ago.