-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coverage: Expose Jacoco Dependencies #12714
Conversation
This changeset exposes aliases for Jacoco and ASM dependencies, which can then be leveraged downstream in projects that extend Bazel and want to include integrated coverage support.
Can this be closed? |
@meisterT I actually do still need it downstream in |
Relates-To: #220 Relates-To: bazelbuild/bazel#12714 Signed-off-by: Sam Gammon <[email protected]>
cc @meteorcloudy who has a project to empty |
I don't think this is the right way to go. If other projects need those dependencies, you can fetch them via rules_jvm_external. We already migrated most of Bazel's java dependencies to rules_jvm_external and plan to do the same for the left overs. |
What do you want to do with this? Use of Jacoco is very much an implementation detail as far as the Java rules are concerned and we make no promises about forever continuing to use it. |
In this (very specific) case, the GraalVM rules may be compiling a Java binary to a native image, and it may notice via Bazel's flags that coverage instrumentation has been requested. We're working with JARs here which were created by Bazel, so they are instrumented with the version of JaCoCo used by Bazel internally. To instrument the native image, an identical version of JaCoCo must be included as an agent during the For users wanting to use some arbitrary version of JaCoCo, they should be consuming that via It would be fine to expose this via the Java toolchain, or via some other internal target that is appropriate for use from rules only. Perhaps the Java fragment could be a candidate? |
|
@fmeum Yes, that may work and would be a better approach. I hadn't seen that, I'll give it a try. Thanks for the pointer |
This changeset exposes aliases for Jacoco and ASM dependencies, which can then be leveraged downstream in projects that extend Bazel and want to include integrated coverage support.