Gradle build system

[Turbo87]

@joel-costigliola would you be interested in moving this project from Maven to Gradle? I addition to that we could merge the other subprojects like the java8 part into this repository by using the subproject support of Gradle.

[joel-costigliola]

I have already give a thought few months ago and it turns out that maven works well for assertj build and release, so no need to change for the time being.

[vlsi]

@joel-costigliola , 8 years have passed. Would you please evaluate Maven vs Gradle once again?

In my experience, Maven creates lots of obstacles as soon as the build goes beyond creating jar file :-(

For instance, when I added ErrorProne, I had to add .mvn/jvm.errorprone.config which is copied by .github/workflows/main.yml as cp .mvn/jvm.errorprone.config .mvn/jvm.config.

Of course, you might want to add those add-opens by default, however, adding non-default options by default sounds scary to me, so I went with copying jvm.config for error-prone only.

[joel-costigliola]

I have had quite bad experiences with gradle, mainly when it comes to debugging it and I'm not keen to give it another try yet unless we find something we can't do with maven.

[vlsi]

Well, have you been using Gradle recently?

1. Kotlin-based DSL yields extremely useful suggestions and type errors, so you can write build scripts via autocomplete, and you can drill down to the implementation.
2. You can put a breakpoint right into the build script. I do not use it often, however, it is super-useful.

---

I moved many non-trivial projects to Gradle, and I could help you move to Gradle if you ask:

• Migrate build system to Gradle apache/jmeter#469. Ant -> Gradle
• CALCITE-3158: Avatica: migrate build system to Gradle apache/calcite-avatica#104. Maven -> Gradle
• [CALCITE-2905] Migrate build system to Gradle apache/calcite#1571. Maven -> Gradle
• chore: migrate build scripts to Gradle pgjdbc/pgjdbc#1627. Maven -> Gradle

The key drivers were slightly different every time, however, I believe Gradle significantly improved developer and user experience in all the cases.

I refined Gradle scripts for projects like

• Split modules testng-team/testng#2564
• Facelift: split plugin to several ones, implement aggregation, migrate to Kotlin allure-framework/allure-gradle#61

---

we find something we can't do with maven

I am sure, with Maven you can't have a human-friendly command line and human-friendly output :(

1. Maven's command line is absolutely cryptic.
   For instance, cp .mvn/jvm.errorprone.config .mvn/jvm.config; ./mvnw -Perrorprone -DskipTests package is far from a human-friendly command line.

With Gradle, the same thing could be ./gradlew -PerrorProne classes or it could even be ./gradlew errorprone.

2. Maven way of printing test results is incomprehensible, and it is noisy. The worst thing is there's no way to adjust the format.
   On the other hand, Gradle provides a much nicer API for the build authors, so failures are easier to notice, the output is less verbose, and it even could integrate with GitHub UI! (see https://github.com/vlsi/vlsi-release-plugins/blob/f946874566ddd495a689024c8b9a9f68933f576f/plugins/gradle-extensions-plugin/README.md )

3. I listed moving error-prone to assertj-parent-pom in Add Error Prone static analysis #2634 (comment)
   I believe it is "unsolvable with Maven". I can't create a PR that edits both assertj-core and assertj-parent-pom.
   With Gradle, assertj-parent-pom is not needed in the first place, and if it exists, then combined PRs are possible just fine.

4. Maven is too verbose. For instance, Java 19-ea job prints 8700+ log lines which makes GitHub Action UI sluggish. Here's an example: https://github.com/vlsi/assertj-core/runs/6645816819?check_suite_focus=true
   Gradle provides a way to hide the noise.

[scordio]

I agree with @joel-costigliola, adopting Gradle in AssertJ would solve a non-existing problem.