If we're looking at other build options, I think we should also consider Bazel. Some advantages I see of Bazel over Gradle:
Gradle is reportedly much slower than Bazel. I haven't measured this myself, but there are many user reports of slow builds, memory leaks, etc. Bazel's build language is based on Python, which more people are familiar with than Groovy (which Gradle uses) Bazel has build rules for building Docker images, which will be very useful in the multi-language world. Of course Gradle has been around longer, and as Luke mentioned is already installed on the Jenkins machines. In general, while Maven has done well for Beam (and prior to Beam for Dataflow) for quite some time, Maven is primarily a Java build tool. As Beam becomes a cross-language platform, I think we're seeing Maven become more of an awkward fit. Our cross language "rules" are essentially just shell scripts, where other build systems can natively manage those rules. We're going to start wanting dependencies between components in different languages, which is going to be difficult to do in Maven. I don't think Maven can completely go away, we still depend on Maven plugins for a number of things (RAT, FindBugs, etc.). Also an initial approach might be to continue using Maven to build Java (for now at least), but to use one of these other build systems to orchestrate the build across all languages. Reuven On Mon, Oct 30, 2017 at 9:37 AM, Lukasz Cwik <[email protected]> wrote: > I wanted to make this thread more visible. This discussion stems from Ken's > thread about Jenkins pre/post commit issues[1]. > > I did some investigation as for ways to improve the quality of the signal > from Jenkins by trying to modify the Jenkins jobs spawned from Groovy. I > had limited success but everything I felt like I was doing was just > patching symptoms of the problem which is that our build is just too slow. > For example, we keep adding all these profiles to Maven or tuning how a > plugin runs to eek out a small decrease in build time. I believe swapping > away from Apache Maven to a build tool which only builds the things which > have changed in a PR would be the best approach. > > I would suggest that we migrate to Gradle as our build tool. I am > suggesting Gradle because: > * It is used in lots of open source projects and has a very large community > behind it. > * It has better support for building languages other then Java > (PyGradle[2], GoGradle[3], ...) > * Its incremental build support works and only builds things that changed > through the use of a build cache. Even without the build cache (or for > clean builds), it is much faster. > * Apache Infra already has Gradle v4.x installed on the Jenkins machines. > > Any alternatives that should be considered or should we stick with Apache > Maven? > > 1: > https://lists.apache.org/thread.html/25311e0e95be5c49afb168d9b4b4d3 > 57984c10c39c7b01da8ff3baaf@%3Cdev.beam.apache.org%3E > 2: https://github.com/linkedin/pygradle > 3: https://github.com/gogradle/gogradle >
