bazel icon indicating copy to clipboard operation
bazel copied to clipboard

Coverage: Expose Jacoco Dependencies

Open sgammon opened this issue 4 years ago • 6 comments

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.

sgammon avatar Dec 17 '20 00:12 sgammon

Can this be closed?

meisterT avatar Dec 14 '23 15:12 meisterT

@meisterT I actually do still need it downstream in rules_graalvm. It would be great if this could eventually be merged.

sgammon avatar Jan 13 '24 00:01 sgammon

cc @meteorcloudy who has a project to empty third_party/

hvadehra avatar Jan 15 '24 15:01 hvadehra

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.

meteorcloudy avatar Jan 15 '24 15:01 meteorcloudy

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.

c-mita avatar Jan 15 '24 15:01 c-mita

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 native-image build. I can put together a reproducer which surfaces the specific exception.

For users wanting to use some arbitrary version of JaCoCo, they should be consuming that via rules_jvm_external et al. But in this case, we need to pin to Bazel's specific version of JaCoCo, since it is effectively being passed on transitively from java_[binary|library].

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?

sgammon avatar Feb 14 '24 08:02 sgammon

JavaToolchainInfo exposes jacocorunner, which embeds the JaCoCo runtime part. Maybe you could extract the JaCoCo package from it in an action?

fmeum avatar Feb 28 '24 15:02 fmeum

@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

sgammon avatar Feb 28 '24 20:02 sgammon