Java Magazine, March/April 2017

ORACLE COM JAVAMAGAZINE MARCH APRIL 2017 60 build Before the days of Apache Maven and Apache Ivy making use of third party libraries was a laborious affair Every time you wanted to include a library you would have to download manually not only its JAR but also any other JARs that it depended on You would then go through a similar process whenever you wanted to upgrade a library Tracking down the necessary transitive dependencies could be particularly painful as could identifying any dependencies you no longer needed Both Maven and Ivy simplified the process by allowing you to declare which dependencies you needed via a set of standard coordinates a group a name and a version The tools took on the responsibility of locating and downloading the necessary JARs for you a process known as dependency resolution Make no mistake automatic dependency management in addition to a single public Java library repository Maven Central fundamentally changed the way Java developers worked This approach has been refined over the years but what you are using now is still at heart the same In fact you might be forgiven for thinking that dependency management is a solved problem Automatic dependency management introduced its own set of issues that can bedevil developers Build tools can and should do more to help because they are best placed to improve the situation If youre interested in learning what that help looks like then read on as I investigate several common challenges of working with Java libraries both third party and your own Consuming Third Party Libraries In an ideal world you would declare your projects dependencies and everything would just work But this rarely happens except in small projects A more likely outcome is that you would encounter one or more of the following issues An unexpected library version that breaks the build or your app library Multiple versions of a library on a classpath Multiple JARs with the same class or classes Unwanted or unnecessary dependencies Dependency resolution that works for some developers but not others The sources of these issues are varied ranging from poorly defined metadata to changes in the names of dependencies And dont underestimate the inherent challenge of keeping a system working that relies on perhaps hundreds of moving parts with each library having its own release schedule time constraints priorities and so on Given that youre likely to encounter problems with dependency resolution unless you never change or upgrade any of your dependencies its crucial that you be able to identify the underlying issues quickly Thats why I think developers deserve better diagnostic tools Diagnosing Dependency Issues You might think that tracking down the source of a version conflict or some other dependency issue is simply a case of looking at the dependency graph You can do this with most PETER LEDBROOK Gradles Java Library Management As builds become more complex library dependencies present a special challenge that build tools are working to solve