Remove duplicated declaration of required OSGi execution environment

[HannesWell]

Description

The bnd-maven-plugin used to generate the OSGi metadata can determine the required EE automatically based on the version of the generated class-files. This avoids inconsistencies if the release target is raised in the future.

In general there is no need to declare a Bundle-RequiredExecutionEnvironment together with an osgi.ee requirement. At runtime the former is automatically converted to the later, since the former is deprecated.
Furthermore declaring multiple values for Bundle-RequiredExecutionEnvironment is also not useful since the driving requirement is the highest one.

With the change being applied bnd generates the following header:

Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"

This matches the minimally required Java version of Java 7 for Gson 2.9 and later and #1601 or #1602 should not be re-introduced.

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

[eamonnmcmanus]

Thanks! I don't think any project maintainers have OSGi expertise but it looks as if you have checked that this does the right thing.

[HannesWell]

Thanks for submitting this.

but it looks as if you have checked that this does the right thing

I have checked the result of a local mvn clean verify build and yes the result is as expected.
Do you deploy snapshots that can be checked again?

And regarding the bnd-maven-plugin:

• Instead of having a separated bnd.bnd file, you could also specify these instructions in a bnd configuration element of the bnd-maven-plugin:
  https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-maven-plugin#bnd-process-goal
  Would you be interested in having that?
• The bnd-maven-plugin could also be used to generate the module-info.class:
  https://bnd.bndtools.org/chapters/330-jpms.html
  This could be used to avoid the need for the moditect-maven-plugin to compile the module-info.java
  Would you be interested in using that?

[eamonnmcmanus]

We don't usually deploy snapshots, no. I think it's very likely that the updated configuration works given your local check, and if by chance the configuration doesn't work we can fix it after the next release.

I like the idea of getting rid of bnd.bnd and using Maven configuration instead. It seems more logical for all configuration to be in pom.xml rather than having this one special file in the top-level gson directory.

On the other hand having bnd-maven-plugin generate module-info.class feels backwards to me. I think we do want to have an explicit module-info.java that users can consult.

[HannesWell]

Sounds all good.
Please see #2712 for the merge.