Some libraries should have deps

[cpovirk]

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 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.]

[cpovirk]

google/flogger#387 has the latest mention of rules_jvm_external, for which we once had #87 open.

[chaoren]

FYI, rules_jvm_external does produce targets with the correct deps, so this should be obsolete once #165 is finished.

[chaoren]

Obsolete after e2204d6. Now some libraries have redundant deps that could be removed instead.