Bnd can cause a .jar to contain the wrong modules’ classes about bnd HOT 5 CLOSED

In the ./okhttp/okhttp-coroutines project directory there is no source in the okhttp.coroutines package but there are sources in the okhttp package. In the whole repository, I can't find a single kotlin file that declares the okhttp.coroutines package?

okhttp/okhttp-coroutines ((parent-5.0.0-alpha.13) *)$ ls -R src
src/main/kotlin/okhttp3:
JvmCallExtensions.kt
src/test/kotlin/okhttp3:
SuspendCallTest.kt
okhttp/okhttp-coroutines ((parent-5.0.0-alpha.13) *)$ cd ..
okhttp ((parent-5.0.0-alpha.13) *)$ find . -name "*.kt" -exec grep okhttp.coroutines {} \;
okhttp ((parent-5.0.0-alpha.13) *)

This does not seem to look right, does it?

from bnd.

Yep. We’ve since moved the code to that and package.

from bnd.

The problem seems to be that if you do split packages, bnd will turn merge them.

The parent-5.0.0-alpha.13 branch has 1 class in the okhttp package: src/main/kotlin/okhttp3/JvmCallExtensions.kt. This will then include ALL classes from the class path in that package since split packages don't work in OSGi without a lot of work and they are evil anyway :-)

If I remove the src/main/kotlin/okhttp3/JvmCallExtensions.kt I get an empty bundle, as expected.

The fact that you do not get an error on the superfluous Export-Package is that sometimes you need to export a package even if you don't have it. When you'd use wildcards it would've warned you.

So I do not think this is a bug. Do not have packages in your source tree that overlap with packages on the build path and you should be ok?

from bnd.

It’s a surprising result but it’s not causing us problems any more.

from bnd.

In bnd, the default always was the classpath, not the project's sources. This made it easy to assemble bundles with their APIs and subsets. However, in this case we have some unexpected interaction. Although I guess it made you find a real problem :-)

from bnd.