Closed HannesWell closed 5 days ago
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
:
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?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?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.
Sounds all good. Please see https://github.com/google/gson/pull/2712 for the merge.
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 anosgi.ee
requirement. At runtime the former is automatically converted to the later, since the former is deprecated. Furthermore declaring multiple values forBundle-RequiredExecutionEnvironment
is also not useful since the driving requirement is the highest one.With the change being applied bnd generates the following header:
This matches the minimally required Java version of Java 7 for Gson 2.9 and later and https://github.com/google/gson/issues/1601 or https://github.com/google/gson/issues/1602 should not be re-introduced.
Checklist
mvn verify
, but can also be checked on its own usingmvn spotless:check
.\ Style violations can be fixed usingmvn spotless:apply
; this can be done in a separate commit to verify that it did not cause undesired changes.null
@since $next-version$
(
$next-version$
is a special placeholder which is automatically replaced during release)TestCase
)mvn clean verify javadoc:jar
passes without errors