search

pubref / rules_maven

Transitive maven dependencies with Bazel.
Other
33 stars 7 forks source link

Allow multiple versions of a single artifact to coexist in a bazel workspace #6

Closed kamalmarhubi closed 7 years ago

kamalmarhubi commented 7 years ago

I'm trying to use org_pubref_rules_protobuf in a project that already loads com.google.protobuf:protobuf-java:jar:2.6.1 (rules_protobuf wants 3.1.0) and com.google.guava:guava:20.0 (rules_protobuf wants 19.0). This results in conflicts like:

An existing maven_jar rule 'com_google_protobuf_protobuf_java' was already loaded with a sha1 value of 'd9521f2aecb909835746b7a5facf612af5e890e8'.  Refusing to overwrite this with the requested value ('e13484d9da178399d32d2d27ee21a77cfb4b7873').
Either remove the pre-existing rule from your WORKSPACE or exclude it from loading by rules_protobuf.

If rules_maven allowed multiple versions of an artifact, perhaps named as bazelified_artifact_name_bazelified_version that would give some flexibility to work around issues like that.

I'm also open to other suggestions on how to deal with this!

I tried the force attribute being added in #5, but it does not help in this case. gradle can't make the dependencies work:

     |    \--- com.google.android.apps.common.testing.accessibility.framework:accessibility-test-framework:2.1
     |         +--- org.hamcrest:hamcrest-core:1.3                                                       
     |         +--- org.hamcrest:hamcrest-library:1.3                                    
     |         |    \--- org.hamcrest:hamcrest-core:1.3                                                  
     |         \--- com.google.protobuf:protobuf-java:2.6.1 -> jar FAILED
pcj commented 7 years ago

As you know, the bazel workspace naming convention is to convert the maven_jar coordinate name to the underscore version, dropping the version number, as in com.google.guava:guava:20.0 -> com_google_guava_guava.

I suppose we could introduce an option to instead include the maven version in the workspace name, such as com_google_guava_guava_20_0.

This has the advantage of isolating different versions of jars into their own workspace, with the disadvantage of facilitating a mechanism by which developers could easily end up with multiple guava versions for a semi-complex project unless they are paying attention. I can see why Google internally discourages this.

I'm not sure I know the right answer, but I think it's reasonable to add an option to include the version in the workspace_name to allow this.

pcj commented 7 years ago

Kamal I've merged #5 and implemented experimental_disambiguate_maven_jar_workspace_names. I think a more granular approach (specify which artifacts should include the version string) would be better, but interested to hear your thoughts.

pcj commented 7 years ago

Should be resolved (some time ago) with the experimental_disambiguate_maven_jar_workspace_names option. Feel free to re-open if needed.