As anyone doing any serious work with Java will be able to tell you, Maven, the software project management tool is not perfect. It is, however, extremely useful and seriously powerful. In a nutshell, it is a tool that lets you easily use 3rd-party libraries in your project while simplifying the build cycle with easily configured plugins that do things like execute unit tests, write metadata for, and package dependencies into one single, final (runnable JAR/WAR) artifact.

I was introduced to Maven pretty early in my career as a software developer. Being an early adopter, I pretty much spearheaded the effort to use it in the development process. After weeks and months of trying out different constellations of plugins, migrating projects from other (older), management tools, like ant, optimizing the build cycle, I recall having everything pretty much streamlined; the build cycle was reduced to a single command. Nonetheless, every now and then, we would run into weird snag - an unexpected but persistent error message that curiously only went away after some debugging. I won’t go into the details here and now, but I believe it all boiled down to two things:

1. Dependencies were treated differently by some plugins depending on whether they were acquired from a local location or from a repository server
2. Dependencies could be installed into a local repository server, in order to be resolved properly, but Maven wouldn’t be able to do such an installation on a new environment, because it would try to resolve the dependency before executing any plugins

So there seemed to be no obvious straight forward way to really bring the build cycle down to the most optimized, most general possible solution - one command; the Maven command; that worked just the same on all environments, old and new.

Unless, of course, you could already have those dependencies on a repository server.

So I deployed a repository server. As essentially all the code I have been working on professionally has been closed source, neither the server nor the repositories were publicly accessible without proper authentication, which of course means that all workstations trying to use my server would have to be authenticated. So there was one more step they had to go through, at some point in time, before they could use the server to single-click-build effortlessly. They had to copy/configure a configuration file to a specific location. So in essence, the more builds any new workstation crunched through, the average number of steps per build would approach one. But to really bring that number down to one - true one - Maven would have to already be configured to use or be authenticated to use the repository server from the beginning.

Enter Maven Central.

Maven Central is a public repository that all Maven installations are configured to connect to by default. The other day, I needed to use one of the home-grown open source libraries I had been working on in a backend service, so I took it upon myself to get it deployed as an artifact on Central. A little bit of research and elbow grease later, and my Steam Web API library is now officially available to all Maven installations, out of the box.

Oh, and to Gradle, Scala SBT, Ivy, Grape, Leiningen and Buildr.

And it goes hand-in-hand with the free tier theme of my last post. I didn’t even have to host my own server.