Use rules_jvm_external to fetch jars dependencies#17112
Use rules_jvm_external to fetch jars dependencies#17112meteorcloudy wants to merge 16 commits intobazelbuild:masterfrom
Conversation
|
FYI @rjobredeaux3 |
aiuto
left a comment
There was a problem hiding this comment.
Nice start. Just some questions and a nit or two.
|
Hey @meteorcloudy , what do sort of review do you need from me? Or is @aiuto 's review sufficient? |
aiuto
left a comment
There was a problem hiding this comment.
This is great.
Will the next phase be to replace the targets java_library targets like //third_party:jsr305 with targets outside of //third_party, so that we eventually reduce //third_party/BUILD to nothing?
Something like that, at least we want to remove all content under third_party that prevents us from checking in this directory into google3. |
|
Thanks for the review, I'll split this change into separate PRs to merge it. |
- Add rules_jvm_external.patch Merging bazelbuild#17112
Non-third_party changes in bazelbuild#17112 Merging bazelbuild#17112
- Delete replaced jar files and update BUILD files. Merging bazelbuild#17112
|
|
||
| load("@rules_jvm_external//:defs.bzl", "maven_install") | ||
|
|
||
| maven_install( |
There was a problem hiding this comment.
Please also use pinning to use bazel's downloader and repo caching instead of coursier.
There was a problem hiding this comment.
Oh, I see, thanks! Does the pinning also work with Bzlmod?
There was a problem hiding this comment.
It should! @shs96c could correct me if it doesn't :)
There was a problem hiding this comment.
Done, please take another look ;)
There was a problem hiding this comment.
Looks like the vendoring of @maven no longer works. glob(["v1/**/*.jar"]) doesn't work anymore since jar files are copied by a genrule from their own repo. Have to figure out a workaround..
There was a problem hiding this comment.
https://github.com/bazelbuild/rules_jvm_external#accessing-transitive-dependencies-list may be useful to generate BUILD rules on the Bazel side if all you need is a way to get the complete list of artifacts.
There was a problem hiding this comment.
OK, I still have to hack rules_jvm_external to make it work. Basically, I need to mock the maven repository for the bootstrap build, which includes vendoring all the jar files and generate a usable BUILD file.
There was a problem hiding this comment.
Pinning works with bzlmod, and if there are problems, that's a bug that we should fix :)
7c9c053 to
dbc9a8f
Compare
Non-third_party changes in bazelbuild#17112 Merging bazelbuild#17112
- Delete replaced jar files and update BUILD files. Merging bazelbuild#17112
This change is required to support Bazel's offline bootstrap build. More context in bazelbuild/bazel#17112 Instead of checking in jar files in Bazel's source tree, Bazel wants to use rules_jvm_external to fetch jars dependencies. However, to support Bazel's bootstrap build, we need to patch rules_jvm_external for vendoring the @maven repository. - Generate a BUILD.vendor file to be used in the vendored `@maven` repository. Added a jvm_import and a filegroup rule for each downloaded jar artifact. The filegroup rule is required by the bootstrap Java toolchain used in Bazel's bootstrap build. The bootstrap Java toolchain cannot depend on a jvm_import target. Because the jvm_import rule depends on a java_binary tool "AddJarManifestEntry", which requires a Java toolchain. Depending on the jar via a filegroup rule helps avoid this cyclic dependency. - Added a filegroup rule to collect all sources needed for vendoring `@maven`, including BUILD.vendor, WORKSPACE and jar files.
Instead of checking in a precompiled jar, following the example of bazelbuild#17112
Instead of checking in a precompiled jar, following the example of bazelbuild#17112
This change is required to support Bazel's offline bootstrap build. More context in bazelbuild/bazel#17112 Instead of checking in jar files in Bazel's source tree, Bazel wants to use rules_jvm_external to fetch jars dependencies. However, to support Bazel's bootstrap build, we need to patch rules_jvm_external for vendoring the @maven repository. - Generate a BUILD.vendor file to be used in the vendored `@maven` repository. Added a jvm_import and a filegroup rule for each downloaded jar artifact. The filegroup rule is required by the bootstrap Java toolchain used in Bazel's bootstrap build. The bootstrap Java toolchain cannot depend on a jvm_import target. Because the jvm_import rule depends on a java_binary tool "AddJarManifestEntry", which requires a Java toolchain. Depending on the jar via a filegroup rule helps avoid this cyclic dependency. - Added a filegroup rule to collect all sources needed for vendoring `@maven`, including BUILD.vendor, WORKSPACE and jar files. - Fix `testonly` attribute handling in Bzlmod. - Set `fetch_sources` to false by default in Bzlmod. - Fix `excluded_artifacts` in Bzlmod. Signed-off-by: kon72 <kinsei0916@gmail.com>
Historically, Bazel checks in precompiled jar dependencies under the third_party directory, which has a few drawbacks:
This PR tries to use rules_jvm_external to replace the checked-in guava jar files and all jar dependencies in guava's transitive clousure. To achieve this and not breaking Bazel's offline bootstrap build, we had to
@mavenrepository and export downloaded jar files.@mavenrepository in the bootstrap distfile.@mavenrepository.This PR doesn't yet replace and remove all checked-in jar files, but it provides a framework to do so and can help avoid #17014
This is also working towards resolving #17036