FWIW Beam also has gpg signing which is a one liner [1] and generates a pom [2] where the latter is very manual unfortunately. We've used all this for the last 5 releases.
One negative is that default of very high parallelism, while good for end-to-end time, can cause OOMs and require JVM heap increases, or blow Jenkins workers if there are concurrent builds. Kenn [1] https://github.com/apache/beam/blob/master/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L1108 [2] https://github.com/apache/beam/blob/master/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L986 On Mon, Mar 11, 2019 at 2:20 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > 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 >
