Understanding Maven Dependency Mediation (Part 1)

The important thing is the version number. It is stated “as is” without any extra additions (I’ll come back to this in a follow-up post). If you define version numbers in this syntax, Maven treats it as a recommended version. So what you’re actually doing is to tell Maven “I would prefer V1.2.11 of Log4J, but hey, I can live with any other version, too”.

This represents the biggest problem I have with Maven. It just feels non-deterministic to me. In solving one problem (“how can we integrate against a large number of jar files from a centralized location and administrate that repository”), we’ve introduced fragility in the resulting build product–we’re not entirely sure what jar files may be loaded and used to build our product.

Now of course this wouldn’t matter if jar files rigorously adhered to a proper API design methodology: proper versioning announcements (like the old Macintosh “Gestalt” manager) or guaranteed a proper and steady evolution of the API calls (similar to what Microsoft does with it’s COM interfaces does with things like IClassFactory and IClassFactory2), along with proper abstraction of the interfaces into higher level operations. Then it wouldn’t matter if you used version 1.0, 1.1 or 8.5 of a particular jar file. And if the API is designed with the principle of Graceful Degradation in mind, it wouldn’t even really matter if you found yourself using version 0.9.

But all this depends on proper documentation, proper design, and knowing the design patterns used by API developers to guarantee that your code will work regardless of what version of the API you’re calling–and when there is an API break, that break is properly announced in a major revision change and how the break will affect you in their documentation set.

But many jar file developers working on smaller projects (especially internal corporate projects) don’t do this–which is why sometimes you can find your code failing as you switch from version 1.1.4 (build 16) and version 1.1.4 (build 18).

Worse, this problem is compounded by the literally dozens of jar files that seem to be sucked in by things like Apache Commons and the Spring framework. If all the moving parts were designed correctly, again this wouldn’t be a problem. But how many people building APIs for common jar files even have any experience designing properly working, properly tested and properly supported APIs? And how many of the potentially thousands of possible combinations are even tested?

It just feels fragile to me.

And when you’re talking about the final build product of your team, after countless months of work trying to get your product solid and stable, fragile is bad.