You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Teach the Java rules to describe their runfiles as named, ordered groups
so that downstream packaging rules can build more efficient artifacts.
`java_binary`, `java_test`, `java_library`, and `java_import` now return
`RunfilesGroupInfo` from the `rules_runfiles_group` ruleset alongside
`DefaultInfo`. Instead of seeing a single flat runfiles tree, a packaging rule
(e.g. a container-image or archive rule) can split a binary's runfiles into
layers and order them so that the content that changes least often lands in the
most cacheable layers:
* the JDK / java_runtime at the foundation tier (never merged),
* `java_import` targets (typically third-party jars) at the shared-deps tier,
* `java_library` code, the binary's own jars, and the executable at the
executable tier, marked `first_party` only for targets in the main
repository -- plenty of Java code Bazel builds from source belongs to
somebody else.
Libraries propagate fine-grained per-target groups up through their dependents
as a depset of group entries, each carrying its own metadata, so what a target
retains does not grow with the size of its closure. The binary collects them,
adds its own groups, and tags every group it produces with the `rules_java`
merge affinity so that JVM-shaped groups stay together when a packager has to
merge groups to fit a layer limit. A dependency that returns `JavaInfo` but no
`RunfilesGroupInfo` -- a custom rule, or `rules_jvm_external`'s `jvm_import` --
gets a synthesized group covering its transitive runtime jars and its default
runfiles, so a packager never silently loses its files. `java_import` gains a
`runfiles_weight` attribute so dependency-management rulesets can hint at
relative sizes to guide those merge decisions.
Emission is off by default and gated on the ruleset-wide
`--@rules_runfiles_group//runfiles_group:enabled` flag, so a build that packages
nothing pays nothing for the providers. Consumers that don't understand
`RunfilesGroupInfo` are unaffected and keep using
`DefaultInfo.default_runfiles`.
Adds a dependency on `rules_runfiles_group` for both Bzlmod and WORKSPACE
setups. It is pinned to a prerelease that only exists in the ruleset's own
registry, so `.bazelrc` points at that registry until a BCR release exists.
0 commit comments