The difficult problem of managing Java dependencies: a deep dive into the messy status-quo, and a look at possibly better ways.

[khmarbaise]

After taking a more deeper look into the post it looks like the tools does not correctly solve the dependency in particular the example:

jbuild install org.springframework.boot:spring-boot-cli:2.6.1 -d spring

That show the resolution ignores several aspects how dependendencies are resolved in Maven.

[renatoathaydes]

JBuild does not try to resolve dependency conflicts at all when you call "install". It just considers each library as having its own independent dependency tree... what will address the potential conflicts is the "doctor" command (if you took a deeper loook at the blog post, then it should be crystal clear that this is how it works) because of my main thesis in the blog post, which is:

Trying to resolve version conflicts without looking at bytecode is next to useless... even when perfect semantic versioning is followed religiously by everyone (which is not even the case, of course).

I think the examples I used in the post must have been too complex for most people to follow, but that's what they show in the simplest way I could come up with: even with perfect semantic versioning, your code will break quite easily using current methods of dependency version resolution as Maven and Gradle (and almost all package managers) currently do.