https://awesomebazel.com/
install bazel
https://docs.bazel.build/versions/master/install-ubuntu.html
https://docs.bazel.build/versions/master/tutorial/java.html
Using Maven dependencies in Bazel
https://github.com/bazelbuild/rules_jvm_external
https://docs.bazel.build/versions/master/migrate-maven.html
https://blog.bazel.build/2019/03/31/rules-jvm-external-maven.html
https://www.braintreepayments.com/blog/migrating-from-gradle-to-bazel/
Bazel’s //… syntax means build everything):
% time bazel build //...
https://brownbear.tech/blog/bazel-maven-jar
maven_jar( name = "com_google_guava", artifact = "com.google.guava:guava:27.0.1-jre" )
After adding the maven_jar statement to your WORKSPACE file, you can start accessing the jar from your project BUILD files. Modify the deps as seen in the example below to add the Google guava library to your project.
java_binary(
name = "project",
deps = [
"@com_google_guava/jar",
],
)
Works best with monorepos
Bazel can be used with a number of project structures but it is most efficient when employed in a monorepo. It uses a file named WORKSPACE to indicate the project root and load dependencies like language plugins. While it is possible to stitch together traditional repos in a multi-workspace configuration it becomes cumbersome resolving and manage third-party dependencies across repos. Multirepos also bring additional overhead as it abandons the maven concept of manually versioned modules. Instead it expects repos to be in the master/HEAD position with changes being committed atomically across the project
The migration process itself for an existing project can be quite labor intensive. There’s a number of tools out there that aim to help (bazel-deps, rules_jvm_external, etc) but none of them are a complete solution. Maven is pretty lax in the specification of dependencies whereas Bazel is quite strict. Part of its speed is not having to solve version compatibility during the build. This means if you’re project isn’t using a BOM to manage versions it’s likely you’ll have multiple versions inflight, something Bazel will reject in the same dependency graph. As a result introduce a BOM and lift all the dependency versions to it before migrating to Bazel
https://codelabs.developers.google.com/codelabs/bazel-android-intro/index.html?index=..%2F..index#2load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "build_bazel_rules_android",
urls = ["https://github.com/bazelbuild/rules_android/archive/v0.1.1.zip"],
sha256 = "cd06d15dd8bb59926e4d65f9003bfc20f9da4b2519985c27e190cddc8b7a7806",
strip_prefix = "rules_android-0.1.1",
)
# Configure Android SDK Path
load("@build_bazel_rules_android//android:rules.bzl", "android_sdk_repository")
android_sdk_repository(
name = "androidsdk",
path = "/Users/codelab/Library/Android/sdk", # Path to Android SDK, optional if $ANDROID_HOME is set
)
bazelbuild/tools_jvm_autodeps (Jadep): Generate BUILD files automatically for an existing Java project with class dependency analysis.
https://docs.bazel.build/versions/master/ide.html
https://docs.bazel.build/versions/master/external.html
s as special:
- The
WORKSPACE
file, which identifies the directory and its contents as a Bazel workspace and lives at the root of the project’s directory structure, - One or more
BUILD
files, which tell Bazel how to build different parts of the project. (A directory within the workspace that contains aBUILD
file is a package
A
BUILD
file contains several different types of instructions for Bazel. The most important type is the build rule, which tells Bazel how to build the desired outputs, such as executable binaries or libraries. Each instance of a build rule in the BUILD
file is called a target and points to a specific set of source files and dependencies. A target can also point to other targets.
Take a look at the
java-tutorial/BUILD
file:java_binary(
name = "ProjectRunner",
srcs = glob(["src/main/java/com/example/*.java"]),
)
In our example, the
ProjectRunner
target instantiates Bazel’s built-in java_binary
rule. The rule tells Bazel to build a .jar
file and a wrapper shell script (both named after the target).bazel build //:ProjectRunner
Notice the target label - the
//
part is the location of our BUILD
file relative to the root of the workspace (in this case, the root itself), and ProjectRunner
is what we named that target in the BUILD
file.
Now test your freshly built binary:
bazel-bin/ProjectRunner
Depending on other Bazel projects
If you want to use targets from a second Bazel project, you can use
local_repository
, git_repository
or http_archive
to symlink it from the local filesystem, reference a git repository or download it (respectively).
For example, suppose you are working on a project,
my-project/
, and you want to depend on targets from your coworker’s project, coworkers-project/
. Both projects use Bazel, so you can add your coworker’s project as an external dependency and then use any targets your coworker has defined from your own BUILD files. You would add the following to my_project/WORKSPACE
:local_repository(
name = "coworkers_project",
path = "/path/to/coworkers-project",
)
If your coworker has a target
//foo:bar
, your project can refer to it as @coworkers_project//foo:bar
. External project names must be valid workspace names, so _
(valid) is used to replace -
(invalid) in the name coworkers_project
.Native rules ship with the Bazel binary and do not require a
load
statement. Native rules are available globally in BUILD files. In .bzl files, you can find them in the native
module.https://github.com/bazelbuild/bazel/wiki/Bazel-Users
https://github.com/bazelbuild/bazel
Before you can build a project, you need to set up its workspace. A workspace is a directory that holds your project’s source files and Bazel’s build outputs. It also contains files that Bazel recognizes as special:
- The
WORKSPACE
file, which identifies the directory and its contents as a Bazel workspace and lives at the root of the project’s directory structure, - One or more
BUILD
files, which tell Bazel how to build different parts of the project. (A directory within the workspace that contains aBUILD
file is a package - To designate a directory as a Bazel workspace, create an empty file named
WORKSPACE
in that directory.
When Bazel builds the project, all inputs and dependencies must be in the same workspace. Files residing in different workspaces are independent of one another unless linked
Each instance of a build rule in the
BUILD
file is called a target and points to a specific set of source files and dependencies. A target can also point to other targets.
java_binary(
name = "ProjectRunner",
srcs = glob(["src/main/java/com/example/*.java"]),
)
bazel build //:ProjectRunner
Notice the target label - the
//
part is the location of our BUILD
file relative to the root of the workspace (in this case, the root itself), and ProjectRunner
is what we named that target in the BUILD
file. (You will learn about target labels in more detail at the end of this tutorial.)
bazel-bin/ProjectRunner
Let’s visualize our sample project’s dependencies. First, generate a text representation of the dependency graph (run the command at the workspace root):
bazel query --nohost_deps --noimplicit_deps "deps(//:ProjectRunner)" --output graph
The above command tells Bazel to look for all dependencies for the target
//:ProjectRunner
(excluding host and implicit dependencies) and format the output as a graph.
Then, paste the text into GraphViz.
When referencing targets within the same package, you can skip the package path and just use
//:target-name
. When referencing targets within the same BUILD
file, you can even skip the //
workspace root identifier and just use :target-name
.
For example, for targets in the
java-tutorial/BUILD
file, you did not have to specify a package path, since the workspace root is itself a package (//
), and your two target labels were simply //:ProjectRunner
and //:greeter
.
Fortunately, the _deploy.jar):
java_binary
rule allows you to build a self-contained, deployable binary. To build it, add the _deploy.jar
suffix to the file name when building runner.jar
(bazel build //src/main/java/com/example/cmdline:runner_deploy.jar
export JAVA_HOME="$(dirname $(dirname $(realpath $(which javac))))"