[WatchDog]

Maven and gradle don't have lockfiles(by default), and have never really had a serious need for them, because dependency declarations generally don't use ranges. The central repositories don't allow versions to be replaced, and artifacts are all signed with PGP keys of the developers(although most people don't verify these).

I've never really seen the value in dependency ranges, they make builds more complicated, and bring minimal value.

[Tainnor]

As far as I know that doesn't solve the problem for transitive dependencies, which can still be resolved to different versions without a lock file.

[WatchDog]

No it’s the same behaviour for transitive dependencies, if two libraries require different versions of the same transitive dependency, the newer one is chosen. Deterministic no lock file required.

[morelisp]

> if two libraries require different versions of the same transitive dependency, the newer one is chosen.

Unfortunately, this is not how maven works. It picks the version required by the dependency nearest in depth to the project root, breaking ties by first listed in the file. It is deterministic, but it's not what anyone ever wants by default.

(This is called "dependency mediation" if you want to Google it.)

[Tainnor]

OK, but that has a whole host of other issues such as the dependency that relies on the older version potentially breaking with the newer version. I think BOMs get around this issue, hence why they're so common, but then it just means that you trade one issue for the other and that's why you have different solutions. A Ruby project, for example, doesn't need BOMs.