extremely difficult to load closure_repositories into an existing bazel project

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](https://docs.bazel.build/versions/master/generate-workspace.html) or [grpc_java_repositories](https://github.com/grpc/grpc-java/blob/master/repositories.bzl)) 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 `@//jar` for or (optionally) shade the names of all java_import_external created targets, (e.g. prefixing w/ "closure_rules_")?

+ @kchodorow (for your insight)

Start with //closure/private:java_import_external.bzl and the closure_repositories definition; reproduce the conflict using the shown Bazel queries and an existing native.maven_jar declaration. Compare the generated export labels with the pre-existing @com_google_code_findbugs_jsr305//jar:jar target. Done means an agreed, compatible dependency-naming and import strategy is documented and verified.

Written by the indexing model from the issue text.