extremely difficult to load closure_repositories into an existing bazel project

[erickj]

Sorry for the epic report...

This is really just a cry for help as I sink deeper into the morass of external repository naming conflicts.

tldr: loading closure_repositories() into a project with conflicting dependency names (e.g. from generate_workspace or grpc_java_repositories) seems nearly impossible to resolve without hacking the closure_repositories rule.

Issue 1: is the non standard naming of external dependencies between major projects, e.g. rules_closure creates com_google_code_gson and grpc-java creates com_google_code_gson_gson. But this issue is relatively well known, and mostly surmountable with some ugly hacks, and is already documented elsewhere:

https://bazel.build/designs/2016/09/19/recursive-ws-parsing.html https://github.com/bazelbuild/bazel/issues/1943 https://github.com/grpc/grpc-java/issues/3328

Issue 2: Seems to be a much bigger problem, specific to rules_closure WRT with importing java dependencies

closure_repositories is generating its own java_import rules via the nonstandard java_import_external rule rather than native.maven_jar rules that is more standard across bazel projects (e.g. grpc-java and migration-tooling generated .bzl files). So for example:

Let's assume I have target @com_google_code_findbugs_jsr305 already declared in my workspace via native.maven_jar, so that:

$ bazel query @com_google_code_findbugs_jsr305//... --output label_kind
java_import rule @com_google_code_findbugs_jsr305//jar:jar
filegroup rule @com_google_code_findbugs_jsr305//jar:file

Then I would expect to load closure_rules via:

closure_repositories(
    omit_com_google_code_findbugs_jsr305=True,
    ...

However, this generates (e.g) a @com_google_guava//:com_google_guava java_import targets with export dependencies on @com_google_code_findbugs_jsr305//:com_google_code_findbugs_jsr305

$ bazel query @com_google_guava//:com_google_guava --output build
# /home/erick/.cache/bazel/_bazel_erick/4fbe1c2851c54abfd26b77789ffadbff/external/com_google_guava/BUILD:7:1
java_import(
  name = "com_google_guava",
  jars = ["@com_google_guava//:guava-21.0.jar"],
  exports = ["@com_google_code_findbugs_jsr305//:com_google_code_findbugs_jsr305", "@com_google_errorprone_error_prone_annotations//:com_google_errorprone_error_prone_annotations"],
)

AFAIK neither bind nor alias will let me declare an alias for @com_google_code_findbugs_jsr305//jar:jar in the @com_google_code_findbugs_jsr305 external repo from anywhere in my project workspace.

So... now I'm stuck (please let me know if I'm not actually stuck, and just missed something). I have a few hacks in mind to make to closure_repositories to just get things working, but I'm wondering...

1. Am I an idiot, and have I totally missed something that makes my problem go away?
2. If not, how are others dealing with this? And whats the plan going forward for rules_closure?
3. Is there a wider discussion with the core bazel team to create clear best practices for rule providers to make this problem stop happening?

For the time being, since //closure/private:java_import_external.bzl seems to be the non-standard naming culprit, would it be acceptable to rename the export targets to the @<repo>//jar for or (optionally) shade the names of all java_import_external created targets, (e.g. prefixing w/ "closure_rules_")?

• @kchodorow (for your insight)

[erickj]

just to follow up on this, I do see that there is an alias made to *//jar for each java_import. While that alone doesn't solve my issues above, it probably simplifies a solution.

[erickj]

This appears to be the same issue as #200 although IIUC it was closed without addressing the comments from @davido here

[sholokhov]

Hi guys! Any updates regarding this issue? I have exactly the same problem. @erickj did you find a solution without hacking closure_repositories directly?

[davido]

In this PR: https://github.com/bazelbuild/rules_closure/pull/239 I was trying to consume java_import_external from Bazel itself, instead of using rules_closure's clone. In upcoming Bazel releases, native maven_jar is going to be discontinued anyway. IOW, what rules_closure is doing is standard way to consume external dependencies in Bazel.

[pcj]

Note: I wrote a special repository rule some time ago to get over this issue. It may be a workaround until this gets easier.

https://github.com/stackb/rules_proto/blob/master/closure/deps.bzl#L8-L33