Bnd fails to generate import package for exported package

[Bram de Kruijff]

Hi all,

using bndtools 3.3.0 we ran into an issue where bnd fails to
automatically generate a corresponding import package for an exported
package when a class in the exported package uses a class from a
private package.

Eg. the resulting manifest looks like this:

Manifest-Version: 1.0
Bnd-LastModified: 1492168735547
Bundle-Activator: foo.bar.impl1.Activator
Bundle-ManifestVersion: 2
Bundle-Name: foo.bar.impl1
Bundle-SymbolicName: foo.bar.impl1
Bundle-Version: 0
Created-By: 1.8.0_111 (Oracle Corporation)
Export-Package: foo.bar.api1;version="1.0.0"
Import-Package: org.osgi.framework;version="[1.8,2)"
Private-Package: foo.bar.impl1,foo.bar.util
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-3.3.0.201609221906


So although the bundle builds without warning or errors and runs and
resolves, it does not "import what you export" resulting in potential
wiring issues.

Explicitly adding the package to the import package list does resolve
it, but this may be a bnd issue?

Example project: https://github.com/bramk/bnd-iwye

Thanks,
Bram

[BJ Hargrave]

Bnd will not generate an import for an exported package if the exported package is not used by any other package in the bundle. Since no package in the bundle uses the exported package, there is no need to substitutably import the package. That is, the exported package could be removed from the bundle and the remaining packages would not even notice.

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

--

BJ

[Bram de Kruijff]

Hi BJ,

On Fri, Apr 14, 2017 at 3:23 PM, BJ Hargrave <b...@bjhargrave.com> wrote:
> Bnd will not generate an import for an exported package if the exported
> package is not used by any other package in the bundle. Since no package in
> the bundle uses the exported package, there is no need to substitutably
> import the package. That is, the exported package could be removed from the
> bundle and the remaining packages would not even notice.

Good to know. Never knew bnd was that smart :)

However that does not explain my situation because
`foo.bar.api1.FooService` is implemented by
`foo.bar.impl1.FooServiceImpl`. Thus the bundle does use the exported
package internally..

observations:
1) When I remove the export declaration, bndtools adds it to the
calculated imports
2) For the impl2 bundle in the test project the import is being generated.

Example project:
https://github.com/bramk/bnd-iwye

Regards,
Bram

[Peter Kriens]

In this case bnd decides that due to the private reference in the same bundle this package is not substitutable for that bundle. I do not recall the details anymore but there are some bad cases that can happen during updates in this situation.

Kind regards,

Peter Kriens

[Bram de Kruijff]

Hi Peter,

Thanks! Good to know it's intentional and not a bug. Not sure the spec
says anything about this scenario? In any case "bad cases" sounds like
something to stay away from, though obviously the details would be
most interesting :)

Best regards,
Bram

[Bram de Kruijff]

ps. note that it does not come up as a private reference warning...

[Jan Willem Janssen]

Hi,

On Sunday, 16 April 2017 12:17:19 UTC+2, pkriens wrote:

In this case bnd decides that due to the private reference in the same bundle this package is not substitutable for that bundle. I do not recall the details anymore but there are some bad cases that can happen during updates in this situation.

I'm not getting it. So, the fact that there's a private package inlined into the implementation bundle causes Bnd to no longer consider the export of the API package it implements as substitutable? Would this imply that more than only the API contract (read: private implementation details) is considered for package substitution?

[Peter Kriens]

Not on spec level, on spec level this is perfectly ok to substitute an exported package that has private references. 

It is all a long time ago and I do not have the time to do the forensics but my recollection is that it was problematic. I do remember spending a lot of time thinking about it though. :-) The original model was to always substitute.

Kind regards,

Peter Kriens