Make the picocli jar OSGi friendly

[raducotescu]

I would like to use the picocli in an OSGi environment for a module of the Apache Sling project - see [0]. Currently, I've embedded the source code, but that makes our Sonar checks fail. Would it be possible to provide an OSGi-friendly jar? The effort should be minimal IMO and would really help us out, without any other implications for other consumers.

[0] - apache/sling-org-apache-sling-committer-cli#4

[remkop]

I’d be happy to help.
Can you clarify what concrete changes you need for the picocli jar to be an OSGi-friendly jar?

[raducotescu]

We just need to add some headers to the jar's manifest file. This is easily achievable with the bnd-maven-plugin [1]. In Sling we work with the bnd.bnd file, since it makes OSGi instructions easier to define and maintain. Should I come up with a PR for you?

[1] - https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin

[remkop]

Yes please, a PR would be great!

[remkop]

Note that picocli uses Gradle (gradle-4.10.2) to build though. The pom.xml is for GitHub bookkeeping.

[remkop]

Merged into master. Please verify.
This will be included in the 4.0.0-beta-2 release later this week.
Many thanks for the PR!

[remkop]

FYI, 4.0.0-beta-2 has been released. It may take a few hours for Maven mirrors to update.
Thanks again for the PR!

[remkop]

@raducotescu Quick question: I notice that the Bundle-SymbolicName header is set to picocli. What are the conventions for the symbolic name? Should this be the "group name" of the artifact Maven coordinates (that is,info.picocli) instead? - Just wondering.

[raducotescu]

I've used the default the plugin sets, which is the name of the folder where the `bnd.bnd` file is. It's just a name and doesn't really have much importance in the OSGi world but if you prefer you can change it to `<groupId>.<artifactName>` for the final release. Or it could stay like it is since it's anyways the name of the artifact, right?