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. > Would java_export work for building the release artifacts? https://github.com/bazelbuild/rules_jvm_external#publishing-to-external-repositories > > 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. > I have a branch that adds a `go_beam_library` rule that runs the `vet` code generator. I can check this into a new `rules_beam` repository if the official repo would prefer to remain bazel-free. The top of the branch is here: https://github.com/gonzojive/beam/tree/bazel/sdks Definition of the `go_beam_library` macro: https://github.com/apache/beam/compare/master...gonzojive:bazel#diff-40e40e35de6636e5d30538fe02c1312cdd477758ff09ad2d9174f0f2856f458aR11 > > 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. >> >
