Migrate from Maven to Bazel when Bazel is stable and cross-platform

[jbduncan]

I'm sure that migrating from Maven to Bazel has been​ thought about by someone on the Guava team already, but I thought that the task might as well be jotted down in an issue on GitHub as a future reminder and a meta-issue for when the time comes.

Perhaps the two most important criteria which Bazel needs to meet before migration can even be started would be:

• Be at a stable version (likely version 1.0 or greater).
• Can run on all the major OSs that Maven supports (or some other reasonable definition of cross-platform). Will likely include widely-used Linux distributions (Ubuntu, Fedora and others), macOS/OS X, and Windows 7+.

Other things to consider:

• Use Bazelisk as the build tool, so that developers don't need to install Bazel beforehand, and so that the build can specify which version of Bazel to download for (arguably) more consistent builds.

[cpovirk]

Thanks. We have some notes about this internally, to which I've added your points.

Dagger moved to Bazel a while back, so we have some reason to believe that it would work. On the other hand, Guava has some special requirements (like GWT testing) that I'm not sure are well supported in Bazel at the moment, so we might end up blocked on those.

[jbduncan]

@cpovirk Do you know if Dagger receives bug reports from its Windows users who wish to build Dagger from scratch?

I suppose that's my main concern with migrating Guava to Bazel too early (disregarding potential issues like GWT), because I am primarily a Windows 7 user, and my experience with the Windows distribution of Bazel version 0.4.x on chocolatey.org is that it fails to even install core dependencies like msys2 correctly.

I raised this as an issue with the Bazel devs some time ago, but I've admittedly not yet tested if more recent versions like 0.5.x work, so maybe my fear is unfounded now.

[cpovirk]

Do you know if Dagger receives bug reports from its Windows users who wish to build Dagger from scratch?

I didn't see anything from a quick search of its bug database, but @ronshapiro would know better.

[ronshapiro]

I haven't received any, but I'd happily accept any request, and we could always set up AppVeyor tests if necessary

[perezd]

Hey, I did the work:
https://github.com/perezd/guava/blob/bazel/README.bazel.md

Above is my branch with this working, checkout the README, and here's a bazel-based travis run:
https://travis-ci.org/perezd/guava/builds/344132470

[gengjiawen]

@ronshapiro Do you have time to migrate guava from maven to bazel. I know gradle but not bazel. A lot of work blocked for limitation of maven.

[ooxi]

This is more of a meta question, but how does Dagger build Maven metadata files for publication on Maven Central?

[perezd]

@gengjiawen Did you happen to take a look at my branch? I did a majority of the work there already.

@ooxi, I don't really understand how that relates to this thread, can you please start another? I'd like to keep this discussion focused. Thanks!

[ronshapiro]

@perezd we have some BUILD files internally that we want to use/transform to the opensource BUILD files that we would want to have, rather than maintaining two sets of build files. I think the initial questions (bazel 1.0, windows+gwt testing) are probably the bigger points right now.

I can take a look at trying to sanitize+export our internal build files and release them in "alpha" mode. That way @jbduncan can test the windows experience. @cpovirk - thoughts?

[gengjiawen]

@ronshapiro How about a pr ? When @cpovirk got time, he can directly review and merge this ?

[ronshapiro]

A PR for something like this won't be so helpful because we already have BUILD files internally. Having two sets is no better (and arguably worse) than just sticking with the status quo until we're ready to adopt Bazel

[gengjiawen]

I mean a pr to convert build system from maven to bazel. Stuch with maven won't get full android support.

[jbduncan]

@gengjiawen I'm personally a bit lost as to what you mean by "full android support". Guava already has Android-specific versions, right? How else would it need to support Android? 😕

[gengjiawen]

Actually no. Guava android version doesn't bundle it's proguard rules. So basically everyone use android-guava need to google or stackoverflow the proguard rules to fix the build and crash problem when enable minify.

[jbduncan]

@gengjiawen Ah okay, thanks for the clarification.

However, I think I agree with @ronshapiro that it's best to wait until the Guava team are themselves ready to open source the Google-internal BUILD files for Guava. That way, it will prevent duplicating existing work done by the Guava team and @perezd.

[perezd]

Or, use my fork until they are ready. That's my plan. I just got tried it waiting.

…

On Fri, Mar 23, 2018, 7:06 AM Jonathan Bluett-Duncan < ***@***.***> wrote: @gengjiawen <https://github.com/gengjiawen> Ah okay, thanks for the clarification. However, I think I agree with @ronshapiro <https://github.com/ronshapiro> that it's best to wait until the Guava team are themselves ready to open source the Google-internal BUILD files for Guava. That way, it would prevent duplicating existing work done by the Guava team and @perezd <https://github.com/perezd>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2850 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABQdjiN_UnygIyvAiQU0zHJtDpwe5_Sks5thQF0gaJpZM4N9GLq> .

[gengjiawen]

@perezd Why not a pr ?

[perezd]

I pinged this thread to determine receptiveness, and it doesn't sound like we have good reception as they have a long term plan they want to execute. My fork is a short term bridge to unblock myself while the team properly sorts this out.

…

On Fri, Mar 23, 2018 at 9:02 AM Jiawen Geng ***@***.***> wrote: @perezd <https://github.com/perezd> Why not a pr ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2850 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABQdrubRXUwCjJ1Iu7GEtZC6mnTjLXFks5thRx9gaJpZM4N9GLq> .

[cpovirk]

Sorry that I haven't replied here.

Our internal BUILD files are much more complicated than basic external one need to be, to the point that it might not even be worth trying to sanitize and export them. It might well be easier to have separate external BUILD files (probably named something like BUILD.bazel in our internal repo so that they don't interfere with the real ones). But @ronshapiro has the experience with this.

[perezd]

If ya'll are interested in accepting mine as canonical for external, I'd be happy to PR. But no pressure.

…

On Fri, Mar 23, 2018 at 10:12 AM Chris Povirk ***@***.***> wrote: Sorry that I haven't replied here. Our internal BUILD files are much more complicated than basic external one need to be, to the point that it might not even be worth trying to sanitize and export them. It might well be easier to have separate external BUILD files (probably named something like BUILD.bazel in our internal repo so that they don't interfere with the real ones). But @ronshapiro <https://github.com/ronshapiro> has the experience with this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2850 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABQdkp_YcuklCu6QJ5o4J353eyS6ZdSks5thS0DgaJpZM4N9GLq> .

[jbduncan]

Bazel hit version 1.0 a good amount of time ago (🎉), so I've updated the topmost message to tick off that requirement.

[jbduncan]

It may also be worth considering using Bazelisk, so that future contributors won't be forced to install Bazel before building the project.

I've added this as a point of consideration to the topmost message of this issue.

[jermowery]

Any updates on this? It would be great for Google libraries to support Bazel

[cpovirk]

This (in concert with Bazelisk and .bazelversion) would also provide us with (I think) a stable version of Java compiler at a given Git commit. That could theoretically help avoid issues like #2173 (comment) and #3990 (by making us consider whether a change in Bazel version will change the output). I'm not sure it really would, but it still seems like at least a marginal improvement over pulling in whatever Java build tools happen to be on the PATH, as we currently do with Maven.

[cpovirk]

One thing we'd want to verify is whether it's still possible to use Bazel to run tests under JDK8 nowadays. It may well be; I'd just want to check.

[perezd]

It is: https://docs.bazel.build/versions/main/bazel-and-java.html#configuring-the-java-toolchains

[cpovirk]

Oh, thanks. And that was fast :)

I got worried by bazelbuild/bazel@c406da0, but your link makes clear that that's just about the "main" runtime, not about the toolchain.

[edit: But by the time we implement this, who knows if either Bazel or Guava will support JDK8 :)]