Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Coverage: Expose Jacoco Dependencies #12714

wants to merge 1 commit into from

Conversation

sgammon
Copy link

@sgammon sgammon commented Dec 17, 2020

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.

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.
@meisterT
Copy link
Member

Can this be closed?

@sgammon
Copy link
Author

sgammon commented Jan 13, 2024

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

@sgammon sgammon marked this pull request as ready for review January 13, 2024 00:16
sgammon added a commit to sgammon/rules_graalvm that referenced this pull request Jan 14, 2024
Relates-To: #220
Relates-To: bazelbuild/bazel#12714
Signed-off-by: Sam Gammon <sam@elide.ventures>
@hvadehra
Copy link
Member

cc @meteorcloudy who has a project to empty third_party/

@meteorcloudy
Copy link
Member

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.

@c-mita
Copy link
Member

c-mita commented Jan 15, 2024

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.

@sgammon
Copy link
Author

sgammon commented Feb 14, 2024

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?

@fmeum
Copy link
Collaborator

fmeum commented Feb 28, 2024

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

@sgammon
Copy link
Author

sgammon commented Feb 28, 2024

@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 sgammon closed this Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants