Switch to Bazel

[adamyi]

I think we can switch from gradle to bazel for faster incremental build speed, better project structure as well as more convenient CI & test.

One other benefit of using Bazel is that it does not run on Windows so we can finally ask Mingquan to change his OS. Just kidding... But still... I think we would probably wait for Bazel team to fix bazelbuild/bazel#1372 so that we can still publish to our artifactory server in order that projects relying on this API have no problem using gradle instead of Bazel.

Or, maybe we could write a script to generate the pom file and publish maven artifacts? But that's probably gonna be kind of patchy.

[adamyi]

@chentc @gaoliyao @MingquanLiu what do you guys think of this

[fanglinchen]

From what you said, Bazel is promising to speed up a lot of things. I guess MessageOnTap core is more test needed. How does Bazel benefit the testing there? If there is a direct benefit you can tell, we can do the same for MessageOnTap Core. For MessageOnTap API, I think unless there is some urgent need, we can wait for the Bazel team's update on this.

[adamyi]

There's definitely no rush on this, since it's just a compiling system - nothing to do with our functionalities. Bazel is still in its early phase in adopting Android. However, Blaze has been doing a great job internally for Android apps. For instance, Maps and Google+ are already being built perfectly fine with Blaze.

If we want to use Bazel, we can definitely switch both repos, and it should speed the compiling up a lot, since compiling Groovy script takes so long. Right now, Bazel has the functionality for external dependencies of another Bazel project as well as non-Bazel project, so it would be fine for us to import dependencies to the core. We don't have to wait for the maven repo releasing support for the core since that is not a dependency of plugins, but we do need maven support for API. With both Bazel and Maven for the API, we could allow plugins to be developed with either maven, gradle, or bazel. A current solution for maven deploying under Bazel can be found at Dagger 2: https://github.com/google/dagger/blob/master/util/execute-deploy.sh

I'm still looking into the automated testing. It seems that the ATST (Android Testing Support Library) is compiled using Bazel, and Bazel does support a handful of special sizes and behavior tags for testing envs: https://docs.bazel.build/versions/master/test-encyclopedia.html