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

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:

[x] 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.

Jun 17 '17 01:06 jbduncan

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.

Jun 19 '17 14:06 cpovirk

@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.

Jun 19 '17 14:06 jbduncan

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.

Jun 19 '17 16:06 cpovirk

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

Jun 21 '17 23:06 ronshapiro

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

Feb 21 '18 02:02 perezd

@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.

Mar 05 '18 15:03 gengjiawen

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

Mar 05 '18 16:03 ooxi

@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!

Mar 05 '18 17:03 perezd

@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?

Mar 05 '18 17:03 ronshapiro

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

Mar 23 '18 04:03 gengjiawen

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

Mar 23 '18 11:03 ronshapiro

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

Mar 23 '18 12:03 gengjiawen

@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? 😕

Mar 23 '18 13:03 jbduncan

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.

Mar 23 '18 13:03 gengjiawen

@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.

Mar 23 '18 14:03 jbduncan

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 < [email protected]> 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 https://github.com/google/guava/issues/2850#issuecomment-375675687, or mute the thread https://github.com/notifications/unsubscribe-auth/AABQdjiN_UnygIyvAiQU0zHJtDpwe5_Sks5thQF0gaJpZM4N9GLq .

Mar 23 '18 15:03 perezd

@perezd Why not a pr ?

Mar 23 '18 16:03 gengjiawen

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 [email protected] 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 https://github.com/google/guava/issues/2850#issuecomment-375714058, or mute the thread https://github.com/notifications/unsubscribe-auth/AABQdrubRXUwCjJ1Iu7GEtZC6mnTjLXFks5thRx9gaJpZM4N9GLq .

Mar 23 '18 16:03 perezd

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.

Mar 23 '18 17:03 cpovirk

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 [email protected] 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 https://github.com/google/guava/issues/2850#issuecomment-375736708, or mute the thread https://github.com/notifications/unsubscribe-auth/AABQdkp_YcuklCu6QJ5o4J353eyS6ZdSks5thS0DgaJpZM4N9GLq .

Mar 23 '18 17:03 perezd

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

Nov 20 '19 18:11 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.

Nov 20 '19 18:11 jbduncan

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

Feb 23 '20 22:02 jermowery

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 https://github.com/google/guava/issues/2173#issuecomment-144106838 and https://github.com/google/guava/issues/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.

Aug 27 '20 16:08 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.

Dec 14 '21 22:12 cpovirk

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

Dec 14 '21 22:12 perezd

Oh, thanks. And that was fast :)

I got worried by https://github.com/bazelbuild/bazel/commit/c406da09d8bf29b2c8739a579008044626d3ec4f, 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 :)]

Dec 14 '21 22:12 cpovirk