bazel: maven_jar does not pull transitive dependencies

I agree. This issue has single handedly ruled out the use of Bazel on recent projects for me. I understand the difficulty of it and am totally into the Bazel Way, but the management of the scores of maven jars I needed was just too much work. Especially when combined with the work needed to get various tools working nicely with Bazel that have ready made plugins in other build systems. (Including, disappointingly, a couple of google projects).

Even though this issue is closed, I just wanted to add that maven transitive dependencies is a real pain point for people thinking of converting to bazel.

The generate_workspace util should at least be packaged so people don’t need to build from source.

If you already have generate_workspace, why not integrate it into bazel and make transitive maven depen dencies becomes true?

This is a deal breaker for me as well. why not support both approaches i.e specifying transitive dependencies explicitly vs automatically pulling the transitive dependencies and let the users decide on whatever they want to do instead of enforcing it?

A project can have a bunch of dependencies which in turn can have more dependencies which in turn can have more dependencies and it goes on…Now If I have 100’s of jar how can we expect a user to verify every single one of them? Moreover how does a user know what to verify besides resolving the version conflicts ? If version conflicts happens so often how come Maven and gradle where able to go so far? For people who want to verify 100’s of jars or whatever the number is It’s them you actually need a tool like generate_workspace (not all regular users) so they can verify when there is a version conflict and be able to fix it by specifying explicitly for those jars that are in conflict.

In short, this is just not user friendly and so the price is huge and again it appears to me that there is no good reason to not support both approaches.

I totally agree with the suggestions and points raised by @pauldraper especially with the following statement he made. I think that is a useful suggestion

That is exactly what is required today. With a transitive rule, you could specify exactly one SHA hash for the entire resolved result. I assume he meant a merkle root hash here.

I also don’t understand why this ticket is closed without proper consensus.

FYI here is one possible approach that seems to work ok: https://github.com/johnynek/bazel-deps

dependencies you have no idea that you’re using end up in your build artifacts

And you generally don’t need to know. Encapsulation + abstraction. You don’t care how a library is implemented, just as long as it works. True, there are times when that is relevant, and you can check.

Regardless, running a program (generate_workspace) to generate a program (WORKSPACE) to generate a program (jar) is odd. A build tool should be able to combine those steps through automation.

(1) Checking in build outputs for a build to work is not very DRY. A build system that requires this is a weird build system indeed.

(2) As pointed out earlier, java_library manages to transitively add dependencies to classpath; we just need that for remote jars.

(3)

make specifying a sha1 for every dependency awkward

That is exactly what is required today. With a transitive rule, you could specify exactly one SHA hash for the entire resolved result.

I don’t see a credible argument for why transitivity is bad.

I agree with Damien that we should still implement pulling transitive dependencies. Given that all other major Java build systems (i.e. Ant/Ivy, Maven, Gradle, etc.) all pull transitive dependencies by default, not having this feature would be a blocker for migrating many Java-based projects from one of these other build systems to Bazel.

Don’t Maven pom files specify the versions for the artifacts that a given JAR depends on?

I don’t think we should disregards doing so. We could restrict it to fully defined version dependency only, i.e. we pull a dependency only if its version is not specified by a version range. That would ensure reproducibility without having to specify sha1 (eventually with an option to force pulling even if we encounter a version range). In the future plan, there is actually a “flag” for that (IMHO this flag belongs to the maven_jar rule)