Add OSGi metadata

[cnoelle]

Do you mind adding some OSGi metadata to the project, so it can be used easily in an OSGi environment?
Like so:
cnoelle@76b3094

The only effect on the resulting jar should be some additional entries in the MANIFEST file, no further dependencies introduced.

[marci4]

Hello @cnoelle,

do you mind telling me where you got the information (any reference to a documentation?)

Best regards,
Marcel

[marci4]

Any update?

[Mikey1982]

You can find the documentation for the Maven-Bundle plugin on [http://felix.apache.org/components/bundle-plugin/] and [http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html]. It may be a good idea to add / tags though.

[marci4]

Any PR is welcome! Including some explanations and possible effects on the current system.

Best regards,
Marcel

[ViToni]

I would suggest going for the bnd-maven-plugin [https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin].
The difference is that the maven-bundle-plugin uses an older bnd version internally and the bnd-maven-plugin is shiny, new ;) and from the bnd creators themselves using a most recent version of bnd (depedning on the referenced plugin version)

[marci4]

@ViToni could you provide additional documentation for me?
To be honest I have no real clue what the idea behind this is, why it is needed and why it needs a special plugin.

Thx
Best regards,
Marcel

[ViToni]

@marci4 If you ever used Eclipse, OpenLiberty or Liferay you used OSGi :)

In Eclipse there are so called plugins which are basically bundles.

Bundles are JARs with their MANIFEST.MF enriched by information of provided and "consumed" packages (and a bit more which is not relevant here).
Provided packages which are considered public API are called public packages.
The bundle might contain more packages but these might be supposed to be used only internally so these are called private packages.
The MANIFEST.MF should also contain (external) packages referenced by classes of the bundle, eg. in this case: org.slf4j which would be called an imported package.
If all JARs contain this information and therefore are budles an OSGi framework can do the wiring and can inform you that there is something missing before you get a ClassNotFoundException (and even more which is not relevant here).
It also allows dynamic updates of bundles, means all bundles depending on a bundle to be updated would be stopped (because they would loose their dependency), the bundle updated, and the depending bundles restarted.

Another aspect of OSGi is that it fosters an API first approach. Think of slf4j. One is just using the slf4j API without having to think about the underlying implementation.

There is more to it than I could write in this comment... this could be a starting point for further reading: https://www.osgi.org/developer/benefits-of-using-osgi/

OSGi is also used for "small" / embedded devices (because it enables one to deploy only changes and it can shorten update times by restarting only changed parts) and as this library is pretty compact it comes natural to try to use it in such space.
The OSGi-metadata in MANIFEST.MF comes at no cost for non-OSGi user.
People could add the metadata on their own but then every OSGi-user would have to do it so it makes sense to add it at the source.

To make a long story short the maven plugin helps in enriching the MANIFEST.MF with the OSGi metadata, exported packages are configured manually (since this what defines your public API) on the other side it "calculates" the imported classes on its own (this can be fine tuned if required eg. if one is using optional dependencies...)
maven-bundle-plugin and bnd-maven-plugin are doing basically the same but the latter is more recent and in active development.