Suggestion for using bnd plugin for JPMS and OSGi Metadata

[juergen-albert]

As discussed in PR #89 here is a Version that takes care of the JPMS stuff.

I have no real clue about gradle, so I only cargo culted that part. Thus there may be more elegent solutions. It also only works for the lib main project and as fas as I can see non of the others.

The Manifest result is:

The Module info now only exists as a compiled class file:

But you can see, that it now also references correctly the required java modules for you, which is nice for jlink. You can get fancy with JPMS if you like and use additional Annotations or an instruction: https://bnd.bndtools.org/chapters/330-jpms.html

[osiegmar]

The version needs to be maintained, manually? This branch is actually 3.0.0-SNAPSHOT

[juergen-albert]

Yes, this would need to be maintained manually. But you don't need to change it with every version you have. I actually made a mistake here, as this should have been just 2.2. If the overall Version where you introduce this is 3.0 this would be the starting point.

Let me quickly explain why is this the case and what is the sense behind it:

In large Applications it can happen, that 2 libraries have been build against different sometimes incompatible Versions of the same library (in the past I often had dependencies to the apache http client, which introduced breaking changes every other day and thus resulted in inconsistent classpaths). OSGi is capable of running multiple Versions of the same Library at the same time and giving everybody the correct packages, they require. For that, packages should be versioned as well, because the classloader in the end only has a classname and a package name to work with.

Thus the smallest organizational unit in Java are the packages and they can evolve individually. If you declare a Package API it makes sense to indicate to the outside world what kind of compatibility to expect if you use Semantic Versioning for that. I'd suggest setting 3.0 as the version. You would only need to change them between your release Versions if you make changes to the API.
Meaning:

• Bugfixes or internal changes (e,g. adding of private methods) in the Package -> no change
• making a change to an API class, where I as a user wouldn't need to do anything in order to stay compatible (e.g. add a new public method I can use for something) -> minor Version bump to 3.1
• Introducing a change that would make my code incompatible -> Major Version bump to 4.0

If you don't want that, you can remove the Annotation and bnd would use your overall version as Package version.

[osiegmar]

Thanks! I'll give it a spin.

[juergen-albert]

Thanks. If you have questions, feel free to get in touch or ask here: https://bnd.discourse.group/

[stbischof]

@juergen-albert Thanks!!!