Unexpected behavior when using Export-Package alongside -includeresources

[thahnen]

Summary

I should start this way: I'm a beginner with with Bnd and have only some experience in working with it, but I consult the official documentation all the time. And so far it is hard to learn, but I like it.

I've noticed a behavior while working with Bnd and Maven. I just cannot explain myself, and I cannot see the reason if it is intended or if it is maybe a bug that is producing duplication. To follow with what I'm saying, there is a simple reproducer project linked somewhere below in this issue - the real-world example for me is some magnitude bigger.

BndExportPackageBugReproducer.zip

I have a Maven project structure like this (the reproducer is simplified to only feature one dependency, the other one is directly in the bundle to show that this combination is also providing unexpected results). The bundle has no source code and is only used to aggregate all of the dependencies into one bundle (the Bnd plug-in is only used here).

The bnd.bnd for the module bundle looks like this:

Export-Package: com.hahnentt.dependency1.api.*;version="${project.version}", \
  com.hahnentt.dependency2.api.*;version="${project.version}",

-includeresource: lib/dependency1.jar=dependency1-*.jar;lib:=true, \
  lib/dependency2.jar=dependency2-*.jar;lib:=true

When running Maven to create the archives, I get the following output that is unexpected:

I was actually assuming it would be either creating something like this based on that the Bundle-ClassPath was generated to be .,lib/dependency1,jar,lib/dependency2.jar:

Another option I thought might be possible (but I'm not sure if packages from stuff on the Bundle-ClassPath can be exposed):

So my question is: Is this expected or not and if it is expected, is there an option to achieve either the first or the second expected option? Having classes twice on the Bundle-ClassPath not only looks like duplication but also may be a potential issue when I'm thinking of having classes more than once on the normal Java classpath :thinking:

[pkriens]

Export-Package has 2 functions. It selects a set of packages to include from the class path and to export, Private-Package also includes but does not export. This was the original design.

However, since the annotations, the modern way is to include the full project classes and then use annotations to indicate which are exported with @Export and @Version in the package-info file. Under the hood, this uses the following instructions:

• -includepackage – Include the given packages and process the annotations, default are all the classes in the project. However, notice that the packages may come anywhere from the class path. I.e. if bundle foo is on the class/build path, you can include its packages.
• -privatepackage – Include the given packages but do not process the annotations, default empty
• -exportcontents – Do not include anything but after -includeresource, and other instructions filled the JAR, export the given packages. Default empty

You can only get the default model (= all project classes) when you do not set any of them. If you touch one or *-Package, etc. you have to set them all.

Now, imho defaults work best. Why on earth do you want to use the Bundle-ClassPath? This is almost always a bad idea. I might be missing something but in your setup, there is absolutely no reason to have any setup in bnd. Just take the defaults and add the package-info.java with the export annotations to the APIs.

[pkriens]

I think this is answered, please reopen if thre are more questions.

[thahnen]

Hi @pkriens,

thanks for your response! This was very helpful, and in the end, I went with the -exportcontents instruction as this is what I wanted to accomplish in the first place!

I've seen this before, but from the instructions documentation page, it only contains so little info that I wasn't sure if the mentioned class path would include the Bundle-ClassPath as well.

Maybe the actual documentation of the instruction could be enhanced a bit? Thinking of the -includeresource documentation that contains a lot of different use cases and combinations with macros. Should I open a new issue ticket for that and maybe propose a small draft - in this case, with my point of view mostly for a combination of Bndtools with Maven?

To answer your valid question why on earth do we use the Bundle-ClassPath :smile: We have a shared library built with Maven that is in no way compliant with OSGi and its annotations that are used among different Java IDEs, in my case, consumed by Eclipse. Its developers have no clue about OSGi (or anything Eclipse / bundle magic related). We use the Bundle-ClassPath so that the bundle that is then used on the Eclipse side is only one (and not many, not one per module) that we can easily exchange and shade other stuff into (this is done via Maven). So using the Bundle-ClassPath is firstly for simplification, secondly for convenience, and thirdly due to the developers having no clue of OSGi, and I'm the only one responsible for creating this Eclipse-specific OSGi bundle. So basically plugging in OSGi in a mostly non-OSGi environment to satisfy the needs of Eclipse ^^

[chrisrueger]

Should I open a new issue ticket for that and maybe propose a small draft - in this case, with my point of view mostly for a combination of Bndtools with Maven?

@thahnen Yes please, documentation improvements are very much appreciated :) A PR would be fine. You can describe the problem solved in the PR description.

[pkriens]

Please submit a PR. However, realize that you might be surprised that the information is already there. A problem with OSGi is that some of its foundational concepts are quite new and that makes them hard to recognize. Once you have tried to explain it to others, it is clear to you why the existing documentation suddenly makes sense.

However, it is true that -includepackage and -privatepackage are relatively new, and also the default to include the project is new. I've described it in several places but it might be nice to have a single page that pulls all this together.

Please make a draft and i will try to contribute to this.