OSGi / bnd: Remove the self-Import of gson.annotations

[chrisrueger]

Closes #2725

Purpose

Fixes a runtime issue in OSGi environments using multiple versions of GSON.

Description

Based on bndtools/bnd#6220 (comment) append -noimport:=true to all exports which we do not want to re-import.
This will remove the package from the Import-Package instruction in the resulting MANIFEST.MF

This avoids issues in OSGi environments where multiple versions of gson are deployed and required by different consumers and com.google.gson.annotations causes wiring conflicts between these different gson versions.

For further information about the -noimport check the bnd manual.

Checklist

• New code follows the Google Java Style Guide
  This is automatically checked by mvn verify, but can also be checked on its own using mvn spotless:check.
  Style violations can be fixed using mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.
• If necessary, new public API validates arguments, for example rejects null
• New public API has Javadoc
  • Javadoc uses @since $next-version$
    ($next-version$ is a special placeholder which is automatically replaced during release)
• If necessary, new unit tests have been added
  • Assertions in unit tests use Truth, see existing tests
  • No JUnit 3 features are used (such as extending class TestCase)
  • If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
• mvn clean verify javadoc:jar passes without errors

Mentioning @Marcono1234 since he was involved in the discussions.

[Marcono1234]

Thanks! I am still not completely sure what the 'correct' approach is (see the discussions you linked), but it is probably worth a try.

@eamonnmcmanus, what do you think?

[chrisrueger]

what the 'correct' approach is

One statement I discovered, which makes me think -noimport is the right thing to do here is this:

Source: https://bugs.eclipse.org/bugs/show_bug.cgi?id=183595#c7

As a best practice I would recommend that library bundles do not import the packages they export. Bundles should only import a package if they are willing to get that package from an unknown source and omit their own export from the framework.

I think Gson qualifies as a library bundle (as opposed to an OSGi based fully fledged application).

I think the important statement is this:

if they are willing to get that package from an unknown source and omit their own export

This could be read e.g. like "I am fine that the package com.google.gson.annotations from gson 2.10 could also be provided by gson 2.11."

• I think this is almost never the case for libraries (because libs never know in which context they are used. A library cares only for their own packages (I don't mean the 3rd party dependencies the lib might need itself))
• especially when the library authors itself do not have OSGi knowledge, and "just" want to provide OSGi meta-data (it is often the case that those libraries are not developed with OSGi in mind, but need to provide the meta-data so that it can be consumed by OSGi apps)

This is different to OSGi based fully fledged applications (like Eclipse, AEM, Liferay).
Those applications consist of multiple OSGi bundles making up the whole application. In such "application" scenarios, special tricks like "package substitution" different bundles providing the same package (see #2725) could be desired. But applications are usually a different "beast" and much bigger than libraries.

I will try to discuss this further with the bnd / OSGi developers, and maybe the result could be a recommendation / documentation improvement for this specific problem.

[eamonnmcmanus]

Thanks, I really don't know anything about OSGi but I'm happy to go with whatever you decide after talking to the OSGi experts.

[chrisrueger]

@eamonnmcmanus thanks for your reply . @bjhargrave has approved this PR and he is THE OSGi expert and longtime bndtools committer.

[eamonnmcmanus]

OK, thanks for doing all this!