Closed cpovirk closed 1 month ago
https://github.com/google/flogger/issues/387 has the latest mention of rules_jvm_external
, for which we once had https://github.com/google/bazel-common/pull/87 open.
FYI, rules_jvm_external
does produce targets with the correct deps
, so this should be obsolete once #165 is finished.
Obsolete after e2204d625d97dda88112af0b0a9e56ed7712d15c. Now some libraries have redundant deps that could be removed instead.
I think I almost filed this issue once before. This time, I'm going to do it for real.
As an example,
asm-tree
should depend onasm
, and andasm-commons
should depend on bothasm-tree
andasm
. Without those deps, it's possible to get errors likeclass file for org.objectweb.asm.tree.MethodNode not found
.The trick is that targets like
asm-tree
arejava_library
targets, which exportjvm_import_external
-generatedjava_import
targets. And whilejava_import
targets can havedeps
,java_library
targets can't havedeps
unless they havesrcs
. (runtime_deps
would be wrong here;exports
is overkill/unhygienic but would at least work.)Possible solutions:
bazel-common
users' projects as errors crop up.exports
(again, "overkill/unhygienic but would at least work").srcs
to an empty srcjar (either one that we check in, though that would likely require compliance exemptions, or one that we autogenerate at build time). Ideally we'd generate only one such jar and share it across libraries.jvm_import_external
can setdeps
(maybe?) or if we should be using something else, likemaven_install
(which sounds more likely to do this for us). [edit: Err, did something named "maven_install
" subsequently become part ofrules_jvm_external
??] (We may have an issue open in one of our projects about whethermaven_install
could largely replacebazel-common
. Compare what gRPC did.) [edit: The thing we currently use ismaven_import
, our wrapper aroundjava_import_external
.]