Skip to content

Conversation

@vinnybod
Copy link
Contributor

@vinnybod vinnybod commented Dec 2, 2025

Description

I have a scala_library with some java files where I would like to override the class for a particular dependency (i.e. something from @maven//).

This is a common idiom for monkey patching some functionality.

In order for this to work, the Java file needs to be first on the classpath.
@rules_scala seems to be placing the generated java_library at the end of the CLASSPATH.

This change makes it so that it's first.

This is a copy of #1752 but with a test added

Co-Authored-By: Farid Zakaria <farid.m.zakaria@gmail.com>
#$runner bazel build --extra_toolchains=//test/toolchains:high_level_transitive_deps_strict_deps_error --all_incompatible_changes -- test/...
$runner bazel test "${test_output_flag}" --extra_toolchains=//test/toolchains:high_level_transitive_deps_strict_deps_error -- test/...
$runner bazel test "${test_output_flag}" --extra_toolchains=//scala:minimal_direct_source_deps -- test/...
$runner bazel test "${test_output_flag}" --extra_toolchains=//scala:minimal_direct_source_deps --build_tag_filters=-no-strict-deps --test_tag_filters=-no-strict-deps -- test/...
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love that I had to do this, but afaik there isn't a way to disable "strict deps" on a target level like you can with "unused deps"

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.

1 participant