Why an extra layer of indirection?

[pauldraper]

Consider publishing a example_tool workspace.

Normally, the client workspace would have

http_respository(name = "example_tool", ....)

load("@example_tool//:workspace.bzl", example_tool_repositories = "repositories")

example_tool_repositories() # default repository definitions

However, if I change to using this project, the client now has to

http_archive(name = "example_tool", ...)

load("@example_tool//:workspace.bzl", example_tool_repositories = "repositories")

example_tool_repositories() # default repository definitions, including rules_jvm_external and maven_install(...)

load("@example_tool_maven//:defs.bzl", example_tool_maven_repositories =  "pinned_maven_install")

example_tool_maven_repositories()

The last two statements seem to be entirely superfluous, especially when the client requires no direct interaction with Maven artifacts. (E.g. Google Closure Compiler is a Java project with third party/Maven dependencies, but it's used by JavaScript developers that hardly need to understand the first thing about JVM/Maven/classpaths.)

---

I think this is an artifact of wanting to operate in a non-pinned mode(?).

In any case the extra WORKSPACE complexity imposed on clients is a regression compared to bazel-deps or hand-coded dependencies.

[pauldraper]

Another thing the indirection provides is the ability for the client to avoid loading a large Skylark file if it does not use it. But I consider that to be a minor cost.

I'd like for my Maven repos to be able to be loaded in a single repositories() call, just like all my other repositories.

[jin]

I think this is an artifact of wanting to operate in a non-pinned mode(?).

This is it. For library/tool maintainers, we recommend the approach of exporting a list of coordinate strings, and concatenating it into the consuming repository's maven_install. This is a lighter weight approach of performing one-version resolution, and avoids futzing around with using a dependency repo's maven_install.json. The client can then decide if they want to use artifact pinning. We should make this clearer in the docs.

See https://github.com/bazelbuild/rules_jvm_external#exporting-and-consuming-artifacts-from-external-repositories

Does this clarify things?

[jin]

I'll close this issue for now, please let me know if you have a proposal to make regular non-pinned workflows work in conjunction with the pinned mode (so users can switch between the two easily) without the indirection of loading from a generated bzl.