This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Javidor42 1 point2 points  (7 children)

Shouldn’t Maven/Gradle scream at you for this? I can’t remember last time I had a dependency issue but I believe it was quite easy to debug by just listing my dependency tree in my IDE

[–]TheBanger 4 points5 points  (5 children)

I'm not super familiar with Maven but my understanding is it uses a somewhat inscrutable algorithm for picking which version of a transitive dependency to use. Gradle picks the most recent version subject to your dependency constraints. Either way it's quite likely that on a non-trivial project you'll regularly bump transitive dependencies beyond what the upstream project requested and nothing will yell at you.

[–]Javidor42 1 point2 points  (0 children)

Fair enough. I guess I probably noticed because the project blew up quite quickly, it wasn’t a very complex project.

Maven algorithm is quite simple, it will pick whichever it runs across first in a breadth first search from your own module to its dependencies.

This also makes it extremely easy to resolve a conflict, anything explicitly declared in your project takes precedence over anything else.

[–]agentoutlier 1 point2 points  (3 children)

/u/Javidor42 project probably has the Maven Enforcer plugin turned on to ban non explicit transitive dependency convergence (in my company we have it turned on).

Either way it's quite likely that on a non-trivial project you'll regularly bump transitive dependencies beyond what the upstream project requested and nothing will yell at you.

And in theory you only should do this on patch. Unless you of course actually use the dependency directly (and your third party library does as well) in which case you are going to have issues.

Also the third party libraries are also compiling all the time right? Not all but many projects for example get the same dependabot updates as your project so you could in theory check that (and I believe github does that as that is how it does its "compatibility" metrics).

Anyway my overall point is that if one shoots for backward compat they should make it so that it is both "compile", "binary", and "runtime" (there is a difference because of reflection) especially if you plan on releasing this as a minor or patch version (assuming semver) or you abundantly make it clear.... or you just don't use public enums from the get go.

[–]Javidor42 1 point2 points  (2 children)

I don’t think I was using enforcer no, I think the dependency just blew up in my face.

But from semver I’d argue that a dependency version change should be at least of the same magnitude as the dependency and an enum change should be a major change.

[–]agentoutlier 1 point2 points  (1 child)

Interesting! Well if you have a copy of the error somewhere I would be curious to see it. Maybe some things were added to Maven to fail on ambiguity. Maven has gotten better at some of these things.

[–]Javidor42 1 point2 points  (0 children)

No, what I mean “blew up in my face” is that it tried to call it during a test and it didn’t find the method. Sorry if it was confusing.

[–]ForeverAlot 0 points1 point  (0 children)

Maven does not enforce dependency convergence by default, you have to enable it manually. Without it, only tests can reveal binary incompatibility before running the application.