Name conflict because . and - are both converted to _

[JaredNeil]

com.google.api.client:google-api-client:1.4.1-beta and com.google.api-client:google-api-client:1.30.10 generate a target named @maven//:com_google_api_client_google_api_client.

I tried using override_targets to rename one or both of them, but it seems that happens after the collision and one of the targets is already lost.

Potential solutions:

• Don't replace - with _
  • com.google.api-client:google-api-client:1.30.10 becomes @maven//:com_google_api-client_google-api-client_1_30_10
  • com.google.api.client:google-api-client:1.4.1-beta becomes @maven//:com_google_api_client_google-api-client_1_4_1_beta
• Don't replace . with _
  • com.google.api-client:google-api-client:1.30.10 becomes @maven//:com.google.api_client_google_api_client_1.30.10
  • com.google.api.client:google-api-client:1.4.1-beta becomes @maven//:com.google.api.client_google_api_client_1.4.1_beta
• Both of the above
  • com.google.api-client:google-api-client:1.30.10 becomes @maven//:com.google.api-client_google-api-client_1.30.10
  • com.google.api.client:google-api-client:1.4.1-beta becomes @maven//:com.google.api.client_google-api-client_1.4.1-beta

Since - and . are both valid anywhere in a target name, I don't see why we have to replace them.

On a related note, the : between group and artifact ID could also be maintained if we wanted to create a package for each group.

• com.google.api-client:google-api-client:1.30.10 becomes @maven//com.google.api-client:google-api-client_1.30.10
• com.google.api.client:google-api-client:1.4.1-beta becomes @maven//com.google.api.client:google-api-client_1.4.1-beta

Then the no-version name would match the artifact coord exactly.

• com.google.api-client:google-api-client:1.30.10 becomes @maven//com.google.api-client:google-api-client
• com.google.api.client:google-api-client:1.4.1-beta becomes @maven//com.google.api.client:google-api-client

[JaredNeil]

I guess #268 would also be a solution to this issue.

[shs96c]

My feeling is that #268 provides a more scalable and neater solution, but would definitely be more work.

[jin]

#268 is definitely a better, more bazel-esque way of solving this problem. I reopened that issue.