joelittlejohn
Unify Maven and Gradle workflows for jsonschema2pojo-gradle-plugin
Currently, both Maven and Gradle are used to build the jsonschema2pojo-gradle-plugin module:
- Maven is used to build the plugin in CI.
- Gradle is used to publish the artifact to the Gradle Plugin Portal.
The preferred workflow would be to have Maven delegate tasks to the module’s Gradle wrapper, using one of the following options:
- https://github.com/raphw/gradle-maven-plugin
- https://github.com/apache/maven-antrun-plugin
- https://github.com/mojohaus/exec-maven-plugin
As an example: https://github.com/raphw/byte-buddy/blob/master/byte-buddy-gradle-plugin/pom.xml
Another option would be to migrate entirely from Maven to Gradle, but a similar issue might arise when testing the Maven plugin.
@raphw Is there any particular reason you’re not using raphw/gradle-maven-plugin in raphw/byte-buddy
Mostly because I am also trying to run the build on old JVMs to test byte code manipulation in these environments. Any plugin makes me struggle with baseline versions.
If you can work out how to do the right invocations for the release, with the correct auth, and wired it to the correct stage of the Maven release, then that would be good. It's hard to get this right, and properly testing is hard too because to simulate the all conditions correctly you really have to do a release.
The gradle build and testing is integrated into overall maven build already, so it's only that release step that needs gradle. I think this is a good compromise for now but it would be great to find an example where another project has got the release working too.
@raphw Could you share your experience with Byte Buddy? Is your solution working well, and do you think it would meet @joelittlejohn’s expectations?
I think it is really working well, because you define a Gradle build and run it as you would from the command line. It needs some adjustments for OS, but alltogether it works really well on most CI and local machines.