cannot load '@rules_jvm_external~5.2~maven~maven//:compat.bzl': no such file

[vorburger]

enola-dev/enola#161 is a PR which upgrades Bazel from 6.1.2 to 6.2.0.

That upgrades causes the following build failure, which did not occur before the upgrade:

ERROR: Error computing the main repository mapping: cannot load '@rules_jvm_external~5.2~maven~maven//:compat.bzl': no such file

I looked into this a bit, and gather that this may or may not have something to do with #880 from @shs96c which was reviewed by @cheister which is mentioned on https://github.com/bazelbuild/rules_jvm_external/releases/tag/5.2?

I indeed cannot find a compat.bzl in this repo, but there are example referencing it, incl. https://github.com/bazelbuild/rules_jvm_external#repository-aliases (and there is a compat_repository.bzl (which doesn't seem to have moved in a while).

My WORKSPACE.bazel looks like the example on the README.

What am I missing?

[vorburger]

@shs96c friendly ping - do you have any idea what could be causing this?

[vorburger]

In the https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/simple, the https://github.com/bazelbuild/rules_jvm_external#repository-aliases works as documented. So this problem is specific to my project (above).

I suspect that @maven//:compat.bzl isn't the same. When I "intentionally break" the working example, it fails as:

ERROR: Error computing the main repository mapping: cannot load '@@maven//:compat--BAD.bzl': no such file

where as in my project it fails as:

ERROR: Error computing the main repository mapping: cannot load '@@rules_jvm_external~5.3~maven~maven//:compat.bzl': no such file

I don't quite understand what defines the @maven repository.

In my project there is a bit of a mix of a maven_install(artifacts = IO_GRPC_GRPC_JAVA_ARTIFACTS, ... in my WORKSPACE.bazel as well as a maven.install(... in my MODULE.bazel.

[vorburger]

I suspect that @maven//:compat.bzl isn't the same.
In my project there is a bit of a mix of (...)

That was it! enola-dev/enola#387 temporarily worked around this (ugly, but it works; I will look into a cleaner solution later), and enabled enola-dev/enola#388 and enola-dev/enola#389 and enola-dev/enola#161 and enola-dev/enola#390 (#NOK).