-
Notifications
You must be signed in to change notification settings - Fork 275
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
Son of "Bad Path Elements" (the next generation) #1374
Comments
I've only so far seen this warning output on the jars imported directly in |
I'm curious why you say
though. I didn't see anywhere in Until recently, |
|
I looked into as well and I seem to think that this chunder should be fixed in Bazel by bazelbuild/bazel@5ea498c, which hasn't been released yet. Maybe in Bazel 6? See also: |
I'm using a pre-release build of bazel 6 which includes this commit, and it does not solve the problem.
Indeed, running the set of repository jars through This works fine because we already use I'll move on to the |
just want to chime in: I (and others) still use https://github.com/johnynek/bazel-deps/ which does not depend on rules_jvm_external (yet?) so I kind of hope we don't require that to set up rules_scala. One hallmark of monorepos and bazel installs is that they are generally highly customized. Putting minimal dependencies on folks is a big plus. |
Yup, makes sense. If we don't want that dependency edge, then i think we need a custom implementation in these rules to do manifest classpath scrubbing like |
Issue #1257 is happening still with modern bazel and rules_scala.
It was discussed in this upstream bazel thread
rules_jvm_external
solves this problem by stripping the classpath elements from the manifest of jars it imports.It looks like
rules_scala
uses its own custom rule implementation to import its dependencies (such asscala-compiler-2.12.14.jar
, which has this manifest entry set). We probably need to do something similar right here, either usingrules_jvm_external
's tool directly (if allowed), or having a similar bespoke implementation which does this if a dependency onrules_jvm_external
from theserules_scala
is not allowed.In the meantime, i'm going to try to solve this locally by replacing the rules dependencies with jars which have already passed through the
rules_jvm_external
manifest rewriting, since we already do use that ruleset. Will report back if this hack works to prevent logspam.The text was updated successfully, but these errors were encountered: