A big reason we chose Gradle over Bazel was that we had a hackathon to implement both, and only one person* chose to work on Bazel while the Gradle team attracted many contributors. Having a build system with more widespread knowledge and interest is an important consideration. Basically I suggest we keep the project as "typical" as possible for each language ecosystem (hence using pip, pytest, tox, etc, go test, docker, etc for different modules), while meeting the requirements of having incremental & caching language-agnostic builds (hence using something like bazel, gradle, make, etc, for the overall build orchestration).
Kenn *that one person was me! On Mon, Jun 6, 2022 at 9:31 AM Andrew Pilloud <apill...@google.com> wrote: > Also I think this belongs on the dev@ list? > > On Mon, Jun 6, 2022 at 9:30 AM Andrew Pilloud <apill...@google.com> wrote: > >> I added Bazel support for building and releasing Java to the ZetaSQL >> repository (based on existing Google internal Blaze configs). From the Java >> side, migrating the build and test is the easy part. Bazel is lacking tools >> to build, test, and ship maven release artifacts for Java. This is >> supported by a gradle plugin today. The scripts that handle this for >> ZetaSQL aren't public as they are brittle shell scripts that break with >> every release. I don't think that approach would scale to Beam. >> >> I would be hesitant to accept changes adding BUILD files without deciding >> we want to cut over to Bazel. Maintaining two build systems is difficult >> and a bazel config that isn't run in precommits would quickly break. >> >> Andrew >> >> On Mon, Jun 6, 2022 at 9:06 AM Robert Bradshaw <rober...@google.com> >> wrote: >> >>> I think it would be useful to see how far bazel has gotten, and it >>> certainly would work better for other languages than java (and >>> cross-language), but I would be careful not to underestimate how large >>> of an undertaking this might be (both technically, and convincing >>> everyone it's a good idea to switch again). >>> >>> Regardless, it would be good to see how much our build system could be >>> streamlined and simplified. Moving stuff out of the build system is >>> probably step one on a project like this. >>> >>> On Mon, Jun 6, 2022 at 12:54 AM Reuven Lax <re...@google.com> wrote: >>> > >>> > It might be a difficult project! We looked into Bazel some years ago, >>> and it didn't quite work out for Beam's needs (though Bazel has presumably >>> advanced in the interim). Creating Gradle build rules for Beam (migrating >>> away from Maven) was an unexpectedly large project - it took multiple >>> engineers a year to complete, and the build has only gotten larger since >>> then. >>> > >>> > Reuven >>> > >>> > On Sun, Jun 5, 2022 at 6:26 PM Red Daly <redd...@gmail.com> wrote: >>> >> >>> >> Hi Beam authors, >>> >> >>> >> Would the project accept github pull requests that add Bazel building >>> functionality? I have been struggling trying to understand how to do some >>> basic things[1] in gradle and might want to just try a build system with >>> which I'm familiar. I expect it might also make it easier to write >>> cross-language and integration tests, though you're probably already >>> achieving that somehow. >>> >> >>> >> Thanks, >>> >> Red >>> >> >>> >> [1] I was trying to build make changes to both the Beam Flink runner >>> and Flink itself but couldn't figure out how to do that. >>> >>
