Move the build to gradle?

[jmini]

As discussed in #162, our builds gets more and more complex and takes to long on small hardware.

If we switch to gradle:

• Build time will be improved (gradle is built to be more performant and to build only changes)
• We can remove the maven-calls-graddle workaround used to build openapi-generator-gradle-plugin
• We benefit for all improvements made in the build tooling area (maven does not evolve that much)
• Optionally, if we find a server to host "Build cache" similar to what Gradle Enterprise provides, we can also leverage this technology. Maybe bintray can be used, it is free for Open Source. I found an article about using Artifactory as distributed build cache. Bintray is a sort of managed Artifactory from the same software editor. Features are similar.

[jimschubert]

Gradle's site has a side-by-side comparison GIF of Apache Commons Lang library building with Gradle (without build cache) vs Maven:

That page lists additional selling points on Gradle.

I'm interested in seeing how the distributed build cache would improve builds.

We can get started with gradle init in the root of the project.

Doing this and running the build exposed an issue with two tests, where I just had to move a temp folder setup to @BeforeMethod rather than field instantiation.

The build in gradle takes 17s:

$ gradle build

> Task :openapi-generator:compileTestJava
Note: CAL10NAnnotationProcessor 0.8.1 initialized
warning: Supported source version 'RELEASE_5' from annotation processor 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less than -source '1.8'
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning

> Task :openapi-generator:test
objc[5592]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java (0x1044d44c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x1222dc4e0). One of the two will be used. Which one is undefined.

> Task :openapi-generator-cli:compileJava
Note: CAL10NAnnotationProcessor 0.8.1 initialized
warning: Supported source version 'RELEASE_5' from annotation processor 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less than -source '1.8'
1 warning

> Task :openapi-generator-cli:compileTestJava
Note: CAL10NAnnotationProcessor 0.8.1 initialized
warning: Supported source version 'RELEASE_5' from annotation processor 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less than -source '1.8'
1 warning

> Task :openapi-generator-cli:test
objc[5593]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java (0x1093124c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x126dff4e0). One of the two will be used. Which one is undefined.

> Task :openapi-generator-maven-plugin:compileJava
Note: CAL10NAnnotationProcessor 0.8.1 initialized
warning: Supported source version 'RELEASE_5' from annotation processor 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less than -source '1.8'
1 warning
Download http://repo.maven.apache.org/maven2/org/slf4j/slf4j-api/1.7.24/slf4j-api-1.7.24.pom
Download http://repo.maven.apache.org/maven2/org/slf4j/slf4j-parent/1.7.24/slf4j-parent-1.7.24.pom
Download http://repo.maven.apache.org/maven2/net/bytebuddy/byte-buddy/1.7.9/byte-buddy-1.7.9.pom
Download http://repo.maven.apache.org/maven2/net/bytebuddy/byte-buddy-parent/1.7.9/byte-buddy-parent-1.7.9.pom
Download http://repo.maven.apache.org/maven2/net/bytebuddy/byte-buddy/1.7.9/byte-buddy-1.7.9.jar
Download http://repo.maven.apache.org/maven2/org/apache/tomcat/tomcat-annotations-api/8.5.31/tomcat-annotations-api-8.5.31.jar

> Task :openapi-generator-online:compileJava
Note: CAL10NAnnotationProcessor 0.8.1 initialized
warning: Supported source version 'RELEASE_5' from annotation processor 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less than -source '1.8'
Note: /Users/jim/projects/openapi-generator/modules/openapi-generator-online/src/main/java/org/openapitools/codegen/online/RFC3339DateFormat.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 warning

Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
See https://docs.gradle.org/4.7/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 17s
24 actionable tasks: 19 executed, 5 up-to-date

And as an example, when no tests have changed, gradle test is aware and succeeds quickly:

$ gradle check

Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
See https://docs.gradle.org/4.7/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 1s
14 actionable tasks: 14 up-to-date

Flipping an assertTrue to assertFalse, only the affected project's tests are compiled and run:

$ gradle check

> Task :openapi-generator:compileTestJava
Note: CAL10NAnnotationProcessor 0.8.1 initialized
warning: Supported source version 'RELEASE_5' from annotation processor 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less than -source '1.8'
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning

> Task :openapi-generator:test
objc[5651]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java (0x1089f04c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x115d184e0). One of the two will be used. Which one is undefined.

Gradle suite > Gradle test > org.openapitools.codegen.java.JavaModelTest.simpleModelTest FAILED
    java.lang.AssertionError at JavaModelTest.java:143

328 tests completed, 1 failed

> Task :openapi-generator:test FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':openapi-generator:test'.
> There were failing tests. See the report at: file:///Users/jim/projects/openapi-generator/modules/openapi-generator/build/reports/tests/test/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
See https://docs.gradle.org/4.7/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 6s
5 actionable tasks: 2 executed, 3 up-to-date

Time differences between the two:

Maven, clean/test (maven has no build cache)

$ time mvn --quiet clean test
…
real	0m28.207s
user	1m3.033s
sys	0m4.350s

Gradle, clean/test (explicitly disable build cache, which is disabled by default)

$ time gradle --quiet --no-build-cache clean check
…
real	0m14.017s
user	0m1.047s
sys	0m0.133s

Gradle, with build cache (I've added org.gradle.caching=true to my ~/.gradle/gradle.properties), consistently within 200ms of the following:

$ time gradle --quiet clean check

real	0m4.783s
user	0m0.943s
sys	0m0.119s

I haven't looked too closely to see if there are additional plugins running as a part of the maven build which would affect the above numbers. This is just a quick run to evaluate.

I've opened #205 with the changes required for the above. I'll spend some time as well looking at what it would take to convert CI scripts.

[alan-czajkowski]

you guys will live to regret moving the build over to Gradle, it may solve some of your problems but will definitely introduce a whole host of new problems that will leave you banging your head against the wall and make you regret the decision to move ... you have been warned

[jimschubert]

@alan-czajkowski can you provide any meaningful or constructive feedback about why you think this? Plenty of large projects use Gradle without fail.

[alan-czajkowski]

the assumption you just made "Plenty of large projects use Gradle without fail" is probably false

here's a few reasons that will make you bang your head against the wall after you've used Gradle for an extensive period of time:

• if you use the Maven release plugin then good luck trying to get that kind of behaviour out of Gradle and the available plugins, there is no Gradle plugin that has feature parity with the Maven release plugin to get exactly the kind of behaviour you would expect, there's a lot of Gradle release plugins, all of them deficient
• Gradle transitive dependency management is so atrocious that Spring had to create this laughable plugin: https://github.com/spring-gradle-plugins/dependency-management-plugin
  • the irony of this plugin? you have to create a Maven BOM (pom.xml) inside your Gradle project in order to get your Gradle project to resolve dependencies properly 😆
• Gradle daemons, that are supposedly there to help you, and improve your build performance, good luck when they don't behave as expected
• Maven resource filtering, still trying to find a good way to do that using Gradle ...

why stick with Maven?

• yes, Maven uses XML, you hate XML, I get it, but what you don't understand is what you're losing when you move from an Object-based project definition to a Gradle build file
  • in an IDE (like IntelliJ IDEA), all of the super convenient syntax highlighting, auto completion, auto error detection of things wrong in your pom.xml (where you misconfigured a plugin, or typo'd an XML tag, or filled something out incorrectly) -- all of that help that you get inside of the IDE, that greatly improves your productivity before ever running a build command -- gone! ... IDEs cannot properly index a Gradle build file to give you the productivity advantages that exist with a Maven build file

[yogurtearl]

@jmini @jimschubert what is the appetite in 2022 for moving the overall build from maven to gradle?
Would you accept contributions for this move?

[alan-czajkowski]

you will regret moving from Maven to Gradle, you have been warned ...
https://phauer.com/2018/moving-back-from-gradle-to-maven/

[yogurtearl]

@wing328 any appetite on moving everything to gradle in 2024?

[alan-czajkowski]

please do not move to Gradle, see all of my comments above

[alan-czajkowski]

and please stop using performance benchmarks to show "speed of Gradle" that have been disproven countless times for average workflows ... Gradle is much more difficult to work with (UX) than Maven, to get the desired results you want out of a build ... Gradle is just the Ant chaos we moved away from (when Maven was introduced), it's just that Gradle has a bit of lipstick on it, meaning: all standards are thrown out with Gradle and your build becomes the wild west again, you can do whatever you want! (this is not good, because then your build is a snowflake, and not transferrable between developers), something we solved with Maven and we are back to losing it now, again, with Gradle