Bazel 9 compatibility - #108
Open
bpalermo wants to merge 1 commit into
Open
Conversation
rules_clojure does not load at all on Bazel 9. Three separate failures,
each only visible once the previous one is fixed:
1. name 'JavaInfo' is not defined
2. no such attribute 'main_class' in 'java_binary' rule
3. no such attribute 'runtime_deps' in 'java_test' rule
Bazel 9 removed JavaInfo and java_common from the Starlark globals, and
reduced the native java_* rules to stubs with a much smaller attribute
set. Fixing (1) alone is not enough: the BUILD files in this repo use
the native java_binary/java_library (2), and clojure_binary and
clojure_test are macros over native.java_binary/native.java_test (3),
so consumers loading java_* correctly still fail inside the macros.
This change is mechanical — load() additions only, no logic changes:
- rules.bzl, rules/{jar,namespace,repl}.bzl: load JavaInfo (15 uses)
and java_common (1) from rules_java.
- rules.bzl: clojure_binary/clojure_test call the rules_java
java_binary/java_test instead of the natives.
- BUILD, src/rules_clojure/BUILD, test/rules_clojure/BUILD and the
three example BUILD files: load java_* from rules_java.
- MODULE.bazel: rules_java 8.16.1 -> 9.7.1, which is what exposes the
java/common:* load paths used above.
- examples/simple/MODULE.bazel: declares rules_java too. It is a
separate module, so the root repo's bazel_dep is not visible to it
and its BUILD files cannot resolve @rules_java without this.
Not a breaking change. `bazel test //...` in this repo passes 5/5 on
BOTH Bazel 9.2.0 and Bazel 8.x, so existing users are unaffected.
Tested with a real consumer as well as the examples here — a four-module
Clojure/gRPC project using clojure_library, clojure_test and
clojure_binary across 12 Bazel targets, green on Bazel 9.2.0 on both a
developer machine and Linux CI.
Author
|
@dancmeyers do you mind taking a look? |
bpalermo
added a commit
to bpalermo/rules_clojure
that referenced
this pull request
Aug 22, 2026
This fork existed for two reasons: to make the rules load under Bazel 9, and to publish the result to the Bazel Central Registry so that Clojure projects on Bazel 9 had something to depend on. The first is done and offered upstream as griffinbank#108. The second is no longer worth doing. bpalermo/rules_clj now covers the same ground as an independent implementation rather than a patched fork — compilation through a persistent worker, deps.edn resolved into a lockfile, BUILD generation, ClojureScript, native images — and maintaining two rulesets that do the same job would mean splitting attention between them and asking users to choose. Nothing is removed. The Bazel 9 commits stay here to be cherry-picked, and griffinbank#108 stays open in case upstream wants it. What changes is the expectation: no releases, no registry entry, and a README that says so before someone adopts it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
rules_clojure does not load at all on Bazel 9. There are three separate failures, each only visible once the previous one is fixed:
Bazel 9 removed
JavaInfoandjava_commonfrom the Starlark globals, and reduced the nativejava_*rules to stubs with a much smaller attribute set.Fixing the first alone isn't enough. The BUILD files in this repo use the native
java_binary/java_library(second error), andclojure_binary/clojure_testare macros overnative.java_binary/native.java_test(third) — so a consumer who loadsjava_*correctly in their own BUILD files still fails inside the macros.What changed
Mechanical —
load()additions only, no logic changes:rules.bzl,rules/{jar,namespace,repl}.bzl— loadJavaInfo(15 uses) andjava_common(1) fromrules_java.rules.bzl—clojure_binary/clojure_testcall therules_javajava_binary/java_testrather than the natives.BUILD,src/rules_clojure/BUILD,test/rules_clojure/BUILDand the three example BUILD files — loadjava_*fromrules_java.MODULE.bazel—rules_java8.16.1 → 9.7.1, which is what exposes thejava/common:*load paths used above.examples/simple/MODULE.bazel— declaresrules_javaas well. It's a separate module, so the root repo'sbazel_depisn't visible to it and its BUILD files can't resolve@rules_javawithout this.Not a breaking change
bazel test //...in this repo passes 5/5 on Bazel 9.2.0 and 5/5 on Bazel 8.x. Existing users are unaffected; Bazel 9 users get a build that previously didn't load.Also tested against a real consumer
A four-module Clojure/gRPC project using
clojure_library,clojure_testandclojure_binaryacross 12 Bazel targets — green on Bazel 9.2.0 on both a developer machine and Linux CI.Happy to split this into three commits by failure mode if you'd prefer, or to adjust the
rules_javaversion if you'd rather pin lower — I picked 9.7.1 because it's current, but the change only needs whatever version first exposesjava/common:java_info.bzl.