In addition to what Mark wrote, I would want to see some of our top open-source Gradle-based Jenkins plugins (e.g., Gradle, Terraform, Checkmarx, Jira Trigger, etc.) upgraded to use the latest gradle-jpi-plugin toolchain, a recent LTS release as the Jenkins core baseline, and a recent plugin Bill of Materials (BOM) and inspect the resulting JPI that is produced to ensure it is up to parity with a JPI produced with the maven-hpi-plugin toolchain (e.g., equivalent manifest entries, equivalent compiler options, etc). Right now, most of the abovementioned plugins are using an ancient Jenkins core baseline and an ancient plugin Bill of Materials (BOM), which does not speak to the viability of the gradle-jpi-plugin toolchain.
In general the gradle-jpi-plugin toolchain needs to be at feature parity with the maven-hpi-plugin toolchain before we could accept new plugin hosting requests. That means, in addition to what Mark described, that every feature in jenkinsci/plugin-pom and jenkinsci/maven-hpi-plugin should have an equivalent in gradle-jpi-plugin, including Java 11/17 support for running unit tests, integration with the latest versions of JUnit/Mockito/Hamcrest out-of-the-box, opt-in code formatting using our project-wide Spotless configuration, equivalents to our Maven Enforcer rules, etc. Since I am constantly adding new features to plugin-pom/maven-hpi-plugin, this implies a commitment to proactively follow such development and sideport the same features to the gradle-jpi-plugin toolchain as they are introduced. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqW5tWqrOGTzmLc5641Q%2BCm19-xzzrzB13K09j5rtzkJA%40mail.gmail.com.
