I see the generate WORKSPACE tool, which is useful.
But an ongoing issue is the pain in transitively adding the N^th dependency. Many of the transitive deps will already have been added, or added with different versions.
It is not clear the best way to tackle this problem.
Ideally, we could run a tool that would load the WORKSPACE, it would merge in a new POM and output a new updated WORKSPACE and BUILD. We would want to control what do to when we see redundant artifacts. Some ideas:
force the user to manually resolve.
just try the latest version and test.
use the tests to try to automatically pick a version (prefer later, but verify by running a test command).
set up a second, differently named external repo pointing at the jar. Find a way to error or warn if two versions of the same artifact wind up in the transitive deps of any one target.
Solution 4. might be ideal since actually putting exactly one version of every target might not be workable.
Post 2
a related issue is upgrading deps. Many will need to be upgraded at a time. If we are using hashes in maven_jar those will all need to be updated and that could be a pretty tedious job by hand.
we maintain our maven dependencies in a yaml file, then it generates the transitive deps with shas and all the targets for the maven graph, normalized to one version per dependency.
It would be cool to have a repository rule do this from within bazel, but there is currently no way great way to do that which I can see, since we can't run jvm code from inside a repository rule. I guess we could pull a compiled jar, then run that jar to generate the dependencies, but so far our dependencies change rarely enough that an external tool is fine.
Migrated from issue 989 in main repository
Post 1
I see the generate WORKSPACE tool, which is useful.
But an ongoing issue is the pain in transitively adding the N^th dependency. Many of the transitive deps will already have been added, or added with different versions.
It is not clear the best way to tackle this problem.
Ideally, we could run a tool that would load the WORKSPACE, it would merge in a new POM and output a new updated WORKSPACE and BUILD. We would want to control what do to when we see redundant artifacts. Some ideas:
Solution 4. might be ideal since actually putting exactly one version of every target might not be workable.
Post 2
a related issue is upgrading deps. Many will need to be upgraded at a time. If we are using hashes in maven_jar those will all need to be updated and that could be a pretty tedious job by hand.
Post 3
by the way, we have pretty much solved this problem with a tool we run along side bazel: https://github.com/johnynek/bazel-deps
we maintain our maven dependencies in a yaml file, then it generates the transitive deps with shas and all the targets for the maven graph, normalized to one version per dependency.
It would be cool to have a repository rule do this from within bazel, but there is currently no way great way to do that which I can see, since we can't run jvm code from inside a repository rule. I guess we could pull a compiled jar, then run that jar to generate the dependencies, but so far our dependencies change rarely enough that an external tool is fine.