How to decrypt resolution result error ?

[Clément Delgrange]

Hi,

I have a project like this:

- bundle a.b.api (A) (compile-only)

      Calculated imports: com.google.guava (20.0.0)

      Private package : -

      Export-package : a.b.api

- bundle a.b.provider (B)

      Calculated imports: com.google.guava (20.0.0)

      Private-package : a.b.provider

      Export-package : a.b.api

The run requirements of the bnd.bnd file of bundle B specifies the bundle B, but the resolution result return :

Unable to resolve a.b.provider version=1.0.0.201611281448:

   missing requirement a.b.api; version=[1.0.0,2.0.0)

This is a little strange because bundle B export a.b.api, and when I use guava 19.0.0 the resolution succeed !

Is there a way to get a more useful message from the resolution process ?

Thanks,

Clement.

[Timothy Ward]

Hi Clement,

Does the API have a uses constraint for com.google.guava? If so then you may have made it impossible for the provider to wire to the API by compiling against inconsistent versions of guava. This is a particular problem with guava as they make every release a breaking version change…

Regards,

Tim

--
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.

[Clément Delgrange]

In both the API and Provider project I specify the use of guava in the same way (adding in build path), and when I change the guava version I do it in the two projects. Is it the case that you have mentioned ? (I don't know how to use constraints).

[Timothy Ward]

Uses constraints apply to an exported package when it exposes types from another API, for example:

package foo;

import com.google.common.collect.ImmutableSet;

public interface MyAPI {

public void checkForReferences(ImmutableSet<Foo> foo);

}

In this case the “foo” API package “uses” the “com.google.common.collect” package. These constraints are generated automatically for you by bnd.

If you then have your API bundle exporting the API at version 1, but importing guava [19,20), and your implementation bundle importing the API at [1,2) and guava at [20,21) then the implementation *cannot* use the API. This is because the uses constraint prevents the incompatible versions of guava from being shared. Without the uses constraint the implementation would be able to import the API and you would get a LinkageError at runtime.

If you are in this situation then the only way to fix it is to make sure that both the API and implementation can share the same version of the used library. This is normally pretty easy, but guava’s version numbering means that no two releases are seen as binary compatible, as a result you need to compile against the same guava version in the API and implementation, or to deliberately widen the guava import range.

I hope that this helps,

Regards

Tim

[Clément Delgrange]

Thank you for your explanations,

So I suppose I am not in this situation since the API and Provider are both updated and build against the same version of guava. Is it possible that Bnd uses the cache to resolve my bundles (kind of version 1.0.0.${tstamp}) ? I don't know what happen in my case but the resulting error seems to be related with what you describe above.

Thanks again, you give me another way to explore ! 

[Clément Delgrange]

After removing reference to guava 19 in my repository and refreshing repos the problem has been solved!

But I spent 3 days for that, It's a little frustrating to not understand what happened :(

But after 3 days, it's nevertheless rewarding, thanks Tim.