bazelbuild
Empty `JavaInfo.transitive_compile_time_jars` for `java_binary` and `java_test` targets
Description of the bug:
As of Bazel 7.1.1, whereas the transitive_compile_time_jars field of JavaInfo providers is populated for java_library targets, it happens to always hold an empty depset for java_binary and java_test targets.
I haven't found any documentation describing such a limitation. Or is there an experimental flag to be turned on to systematically populate this field?
A workaround consists in emulating it by filtering the non-source jar from the inputs field of the first action in target.actions whose mnemonic is "Javac", but it isn't very structural.
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
From an aspect rule implementation:
def _aspect_impl(target, ctx):
if ctx.rule.kind in ("java_binary", "java_test"):
print(target[JavaInfo].transitive_compile_time_jars) # will print an empty `depset`
Which operating system are you running Bazel on?
Ubuntu 22.04.4 LTS
What is the output of bazel info release?
release 7.1.1
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
No response
Have you found anything relevant by searching the web?
Nope.
Any other information, logs, or outputs that you want to share?
No response
AFAIK this has always been the case, and is WAI. java_{binary,test} targets are meant to be terminal/top-level nodes in the build graph, and not included as deps for other Java targets - so they don't contribute any compile/runtime artifacts.
If you're just looking to inspect the target (in an aspect), you could use the binary's JavaInfo.compilation_info.{compilation_classpath,runtime_classpath} instead, which has the equivalent information.
@hvadehra I don't deny that this has always been the case. What bothers me is that the doc doesn't reflect this very fact. So it doesn't matter?
No, you're right, I think adding a note to the docs mentioning this could be useful.
We're actually in the process of a doc audit at the moment to improve things. I'll add this to the list.