Question

My customer needs a more organized inventory of all 3rd-party libraries (such as JAR files) that are used in production for their projects. I am involved with a number of their Java-based projects. Their inventory has not been consistently maintained in the past and the time has come to account for all the libraries that are currently being used (there are quite a few!) and to enforce a structured process for introducing new libraries into the build environment.

I have tried pitching the idea of using Maven and Artifactory in their build process to leverage those tools ability to manage a repository of binary libraries and handle transitive library dependencies. The customer is resistent to the suggestion because they think it will create more work for them to maintain an Artifactory server and learn the basics of Maven.

Currently, their Java projects are all built using Ant scripts. Transitive dependencies are largely managed by trial-and-error. The inventory of libraries currently in use is maintained by hand and the binaries are stored in a Subversion repository. The customer recognizes that this needs to be improved, but the current suggestions for improvement involve more ad-hoc "manage it by hand" approaches.

I want to convince the customer that a combination of Maven and Artifactory is a viable off-the-shelf solution for their Java library management needs. Can anyone direct me to literature/materials that I can use to create a presentation for my customer on the features and strengths of Maven and Artifactory?

Any other arguments/suggestions/etc that would assist me in this would also be appreciated.

Answer 1

I want to convince the customer that a combination of Maven and Artifactory is a viable off-the-shelf solution for their Java library management needs.

As pointed out in a comment, your customer doesn t necessarily need to fully adopt Maven to benefit from dependency management, you could adapt the existing ant scripts to use the Maven Ant tasks or Ivy. This might be less scary and already remove some pain.

Regarding the way Maven manages dependencies, I would simply explain that:

An artifact is identified by coordinates (groupId, artifactId, version).
This allows to store store them using a standardized directory structure (a repository)
A dependency is more that a JAR: it s a JAR with a POM which enables things like transitive dependencies resolution.

And the benefits of such a dependency management solution are:

no mess with dependencies, they are uniquely identified (no more "what version is that?" syndrom)
no more binary data in the VCS (faster checkout, less space)
easier reuse of artifacts between projects (no more jars sent by email)
easier management with transitive dependency resolution

And because you don t want to rely on public repositories, because you need to store your own artifacts, you need an enterprise repository. My personal choice would be Nexus:

because it s file based (unlike Artifactory, and I don t want to put my artifacts in a database)
because it s simple to install/use
because it s easy to administrate

Here are some resources about Nexus (sorry, I just don t use Artifactory):

And just in case, here are some presentation material about Maven:

Several presentations by Arnaud Héritier.
Maven 2.x by Jason van Zyl.
Maven 2.0 - Improve your build patterns by Vincent Massol.
3.5. Core Concepts in the Maven Definitive Guide

友情链接