Given this plugin is not officially supported, we already run builds internally on Java 17, and maven-hpi-plugin requires running with Java 11, I'm currently leaning toward starting to depend on newer libraries and making Java 11 required. If anyone is watching this repository and has input, please feel free to comment. I plan on making a decision in the next week or so.
Background
Recent Jenkins tooling, like lib-access-modifier, require Java 11 or newer.
One simple way to support this is to upgrade and require all builds run Gradle with Java 11 or newer.
Another option is using Gradle Toolchains. Practically this allows us to declare a minimum of Java 11 for the tasks that run these tools, but still allow Gradle itself to run with Java 8.
Cons of this approach are:
an older version of access-modifier has to be on the compileOnly classpath to continue working with Java 8. This will miss future API changes. It may be possible to extract a Java 8 API from access-modifier, but this would require additional work and maintenance.
an older version of access-modifier has to be on the testImplementation classpath to continue to run tests with GradleTestKit.
users must be aware of toolchains, configuring their builds to download from the appropriate place or disable downloads all together.
Given this plugin is not officially supported, we already run builds internally on Java 17, and maven-hpi-plugin requires running with Java 11, I'm currently leaning toward starting to depend on newer libraries and making Java 11 required. If anyone is watching this repository and has input, please feel free to comment. I plan on making a decision in the next week or so.
Background
Recent Jenkins tooling, like lib-access-modifier, require Java 11 or newer.
One simple way to support this is to upgrade and require all builds run Gradle with Java 11 or newer.
Another option is using Gradle Toolchains. Practically this allows us to declare a minimum of Java 11 for the tasks that run these tools, but still allow Gradle itself to run with Java 8.
Cons of this approach are:
compileOnlyclasspath to continue working with Java 8. This will miss future API changes. It may be possible to extract a Java 8 API from access-modifier, but this would require additional work and maintenance.testImplementationclasspath to continue to run tests with GradleTestKit.