Use the artifact macro for loading maven deps

[AutomatedTester]

The recommended way to load dependencies from rules_jvm_external is to make use of the @maven workspace, and the most readable way of doing that is to use the artifact macro provides.

This removes the need to generate the "compat" namespaces, which rules_jvm_external provided for backwards compatibility with older releases. This change also sets things up for supporting bzlmod: this requires all workspaces accessed by a library to be named "up front" in the MODULE.bazel file. This way, the only repo that needs to be exported is @maven, rather than the current huge list.

Finally, this PR introduces a lock file for rules_jvm_external which improves local build times by avoiding the need to do a local resolution. In order to avoid the common failure case of "add a dep, forget to regenerate the lock file", the fail_if_repin_required attribute is set: builds will fail if the deps have been updated but the lock file hasn't been.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: AutomatedTester / name: David Burns (579c97a)
• ✅ login: ejona86 / name: Eric Anderson (4944d5b, ac40960, 46eb721, 52cccdb, 8d10eca)

[ejona86]

We've been purposefully avoiding using @maven directly since using it would require our users to use maven_install and they needed time to migrate. It's probably been long enough. Let me double-check the state of things.

[shs96c]

I'm +1 for this PR. Thank you for double-checking @ejona86!

I'm one of the maintainers of rules_jvm_external, and did the work to make it play nicely with bzlmod. I've not implemented the backwards compat libraries there because the user experience with them is so poor --- essentially, someone using them will need to list the transformed name of every single first-order dependency in their MODULE.bazel. For grpc-java, that's a pretty long list, which will need to be maintained in lock-step with any new imports added. The alternative (of using @maven) is significantly less work and (more importantly) a lot less error-prone.

Until grpc-java is modularised (#9559) anyone who transitively depends on grpc-java in their modularised builds would need to maintain this list themselves, and it would require support in rules_jvm_external that I'm not keen on putting there.

[ejona86]

Must we have maven_install.json? I looked into that earlier and it seems super-annoying; basically meaning any version bumps can't be backported without manual conflict resolution. And all dependency changes must be made serially. I know you lose some things without it, but it solves problems we don't have and creates problems we don't need.

[shs96c]

TL;DR: it's fine not to use the lock file.

There's no need to use it, but it makes builds more reproducible. Builds may also be faster, since they can skip the dependency resolution step: I'm not sure how much of a difference that makes for you, and Bazel should be caching the results until the bazel server shuts down.

[ejona86]

1.33.0 removed the manual maven repos from repositories.bzl, so it seems pretty safe to do this. The only risk I see is someone is using a tool other than maven_install to manage these deps, but I think it is worth a try to do this and see if any issues crop up.

[ejona86]

Hmm... I don't know how #9559 will impact this (or everything, really)

[keith]

it would be great if we could merge this, I have a local change that supports bzlmod for this repo but it either depends on this or breaks compat w/ the non-bzlmod setup

[keith]

awesome!

[ejona86]

@temawi, let me merge this once you approve, as I'll need to fix up the commit message.