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
I think I almost filed this issue once before. This time, I'm going to do it for real.
As an example, asm-treeshould depend on asm, and and asm-commons should depend on both asm-tree and asm. Without those deps, it's possible to get errors like class file for org.objectweb.asm.tree.MethodNode not found.
The trick is that targets like asm-tree are java_library targets, which export jvm_import_external-generated java_import targets. And while java_import targets can have deps, java_library targets can't have deps unless they have srcs. (runtime_deps would be wrong here; exports is overkill/unhygienic but would at least work.)
Possible solutions:
Continue to live with it, adding transitive deps explicitly to the targets in bazel-common users' projects as errors crop up.
Use exports (again, "overkill/unhygienic but would at least work").
Set 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.
See if jvm_import_external can set deps (maybe?) or if we should be using something else, like maven_install (which sounds more likely to do this for us). [edit: Err, did something named "maven_install" subsequently become part of rules_jvm_external??] (We may have an issue open in one of our projects about whether maven_install could largely replace bazel-common. Compare what gRPC did.) [edit: The thing we currently use is maven_import, our wrapper around java_import_external.]
The text was updated successfully, but these errors were encountered:
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
.]The text was updated successfully, but these errors were encountered: