In the previous posts in this series, we’ve talked about how a repository manger changes the development cycle. In this post, I’m going to talk about how a repository manager can be used as a way to interact with third parties. Specifically, I’m going to talk about vendors and partners.
In the last post of this series we talked about how a repository manager, when coupled with a continuous integration server, allows you to work on individual modules in complex multi-module projects. In the post before that, we talked about the repository as something that enables greater collaboration between workgroups. In this post, I explore how using a repository manager simplifies deployment.
The following diagram shows the process of pushing code to production and automating a deployment:
In the first part of this series, I gave you a glimpse at the big picture of repository management, and I listed some common anti-patterns present in systems that haven’t yet installed a repository manager. In this post, I’m going to focused on the benefits a repository manager has on the development cycle. How does using a repository manager change the way your developers will approach development? What problems does it solve? And what possibilities does it introduce?
Whenever I speak to someone doing Java development, I always ask if they are using a repository manager. Repository managers are still an emerging technology, but I’ve noticed a consistent trend: more and more developers view a repository manager as an essential part of development infrastructure. This certainly wasn’t the case just two years ago, and I think that the big motivator behind this trend is that the quality and stability of Maven Central has improved remarkably because of the efforts of people like Brian Fox and others who are focused on making the service more stable.
Another reason why we’ve seen more adoption is that most developers understand the benefits of using a tool like Maven for automatic dependency management. In 2005, it was common to see projects store binary JARs alongside source code in projects. In 2010, you rely on the repository and the metadata it contains. If you use a library like Guice, you’ll add a dependency on the artifact and let your build tool take care of the details. To do otherwise would be to commit yourself to a manual work updating JARs and testing dependencies each time a new version of an external library is released.
Despite the increasing prevalence of repository managers, I still stumble upon workgroups and organizations that haven’t heard of repository management. When you ask if they are using a repository manager, they might think you are referring to Subversion or source control. This series of posts is a high-level overview of the main benefits of repository management. If you are trying to convince someone to start using a repository manager, the next few blog posts are for you.
Continue reading →