top | item 44814092

(no title)

tonsky | 6 months ago

One of the versions will be picked up. If that version doesn’t work, you can try another one. The process is exactly the same

discuss

order

Joker_vD|6 months ago

> If that version doesn’t work, you can try another one.

And how will this look like, if your app doesn't have library C mentioned in its dependencies, only libraries A and B? You are prohibited from answering "well, just specify all the transitive dependencies manually" because it's precisely what a lockfile is/does.

tonsky|6 months ago

Maven's version resolution mechanism determines which version of a dependency to use when multiple versions are specified in a project's dependency tree. Here's how it works:

- Nearest Definition Wins: When multiple versions of the same dependency appear in the dependency tree, the version closest to your project in the tree will be used.

- First Declaration Wins: If two versions of the same dependency are at the same depth in the tree, the first one declared in the POM will be used.

deredede|6 months ago

It's not "all the transitive dependencies". It's only the transitive dependencies you need to explicitly specify a version for because the one that was specified by your direct dependency is not appropriate for X reason.

deredede|6 months ago

Alternative answer: both versions will be picked up.

It's not always the correct solution, but sometimes it is. If I have a dependency that uses libUtil 2.0 and another that uses libUtil 3.0 but neither exposes types from libUtil externally, or I don't use functions that expose libUtil types, I shouldn't have to care about the conflict.

shadowgovt|6 months ago

This points to a software best-practice: "Don't leak types from your dependencies." If your package depends on A, never emit one of A's structs.

Good luck finding a project of any complexity that manages to adhere to that kind of design sensibility religiously.

(I think the only language I've ever used that provided top-level support for recognizing that complexity was SML/NJ, and it's been so long that I don't remember exactly how it was done... Modules could take parameters so at the top level you could pass to each module what submodule it would be using, and only then could the module emit types originating from the submodule because the passing-in "app code" had visibility on the submodule to comprehend those types. It was... Exactly as un-ergonomic as you think. A real nightmare. "Turn your brain around backwards" kind of software architecting.)

Revisional_Sin|6 months ago

So you need to test if the version worked yourself (e.g. via automated tests)? Seems better to have the library author do this for you and define a range.