Julian> One of the awesome things about maven has been how my IDE (Intellij) can load projects automatically
You know what? Not only I can load Gradle-based project automatically. I can debug (!!) Gradle build script right from my Intellij. Oh, I just set a breakpoint inside a build script, and watch variables, perform it step by step, etc. This is really amazing. It is not like I do it often, but, you know. Being able to write unit tests for build system could help as well. Julian>my IDE (Intellij) can load projects automatically There's extra integration like gradle script can update IntelliJ (and Eclipse) configuration via dedicated APIs. For instance, gradle script can automatically configure proper "license headers" for the project. It does improve experience. Julian>It was tricky to get the release process working in Maven. Anyone who has not been a release manager might not realize this It is true what you say. I've pushed stuff to Central via Maven, and I do agree maven-release-plugin/nexus-staging/whatever are quite complicated to configure for non-trivial projects. However, it looks like Gradle can simplify lots of release steps. There are plugins (think of it like of a "jar with code"), and we can just add our own code to buildSrc folder in Calcite repository which automatically becomes a part of a build system. Then we can do whatever logic we need. Julian>There are details like signing, upload of tar balls to svn, upload of jars to nexus, the naming of tar and jar files, and the contents of those files, and generating an intermediate git commit so that the release is exactly based on a labeled git commit. That's what I design for JMeter right now. I don't have exact code samples to share yet. In Gradle, "project version" is a java.lang.Object, so its toString represents the version. That is we don't have to actually update version in the source code. We can just always have "current version" in the source code which automatically becomes a non-snapshot one when the build is triggered with a "release" parameter. That enables us to just add a tag on "preexisting" git commit, and build it as "release candidate 1". That's it. If that succeeds we can build exactly that commit id as a "release". Rollback is trivial: we just drop staging repository from Nexus, and we remove files from dist.apache.org. There's no need to dance with source code branches. We don't really have to remove the tag. On top of that, Gradle has reproducible builds option. For instance, when I build JMeter source/binary artifacts (zip, tgz files), I get exactly the same SHA. Isn't that cool? Julian>We’ll also need to generate pom.xml files for nexus and ultimately maven central I don't suggest to start collecting the checklist here. I do know it will be quite big (e.g. you check out https://github.com/apache/jmeter/pull/448) I don't think there will be technical limitations that would prevent use of Gradle. It would be valuable though if someone could share something on the negative experience though. Vladimir
