If you use two dependencies, and one requires Foo 1.2.3 and the other Foo 1.2.4 then 99% of the time including either version of Foo will work fine. (I was a Java developer and used Maven for about 10 years.)

For those times where that's not the case, you can look at the dependency tree to see which is included and why. You can then add a <dependency> override in your pom.xml file specifying the one you want.

It's not an "insane" algorithm. It gives you predictability. If you write something in your pom.xml that overrides whatever dependency your dependency requires, because you can update your pom.xml if you need to.

And because pom.xml is hand-written there are very few merge conflicts (as much as you'd normally find in source code), vs. a lock file where huge chunks change each time you change a dependency, and when it comes to a merge conflict you just have to delete the lot and redo it and hope nothing important has been changed.

▲

zdragnar 4 days ago | parent | next [-]

> You can then add a <dependency> override in your pom.xml file specifying the one you want.

Isn't that basically a crappy, hand-rolled equivalent to a lock file?

▲

smrtinsert 4 days ago | parent | next [-]

A single override does not equate to an entire lockfile of dependencies.

	▲	zdragnar 3 days ago \| parent [-]
		And yet, that one manual override and an auto-generated lockfile require basically the same level of effort, and serve the same purpose. Edit: actually, depending on the package manager, the auto generated lockfile takes less work than the single override, as they don't have the same issue maven does to require an override in the first place.

▲

Muromec 4 days ago | parent | prev [-]

Of course it is

▲

int_19h 4 days ago | parent | prev | next [-]

What happens when one requires Foo 1.0 and the other requires Foo 2.0, and the two are incompatible on ABI level?

▲

tpm 3 days ago | parent | next [-]

When you are building some app in an ecosystem not entirely managed by you, things like this are bound to happen, so there are always ways to solve this.

You use Foo1 in Project1 (= one pom.xml) and create Project2 (=second pom.xml) where you use Foo2 (but package it in such a way that Foo2 is not exported from Project2), and depending on the usecase create a thin wrapper which you can then use from Project1, as an absolute worst case.

▲

jameslars 4 days ago | parent | prev | next [-]

Notably, a lockfile does not solve this problem either.

	▲	omcnoe 3 days ago \| parent [-]
		True, but the lockfile is imposed at build time. Swapping out the version of a transitive dependency might build totally fine, but also might result is broken behaviour at runtime if the behaviour of the dependency changed.

▲

Muromec 4 days ago | parent | prev [-]

Then you sit and cry of course

▲

ffsm8 4 days ago | parent | prev | next [-]

Depending on the dependency, you can also use shadow versions right? Essentially including both versions, and providing each dependency with it's own desired version. I believe it's done with the maven shade plug-in

Never used it myself though, just read about it but never had an actual usecase

▲

lostmsu 3 days ago | parent | prev [-]

Yes, but if later Dep1 and Dep2 stop depending on Foo you will never know about it.