Repository Management with Nexus
2.6. Reasons to Use a Repository Manager
Here are a few reasons why using a repository manager is an imperative. While most people wouldn’t even think of developing software without the use of a source code control system like Subversion or Perforce, the concept of using a repository manager is still something that needs development. There are many who use Maven for years without realizing the benefits of using a repository manager. This section was written as an attempt to capture some of the benefits of using a repository manager.
When you run your multi-module project in Maven, how do you think Maven knows if it needs to update plugins or snapshot dependencies? It has to make a request for each artifact it needs to test. Even if nothing has changed, if your project depends on a few SNAPSHOTs or if you don’t specify plugin version, Maven might have to make tens to hundreds of requests to a remote repository. All of these requests over the public Internet add up to real, wasted, time. I’ve seen complex builds cut build time by 75% after installing a local instance of Nexus. You are wasting time better spent coding waiting for your build to needlessly interrogate a remote Maven repository.
The larger the organization, the more critical bandwidth savings can be. If you have thousands of developers regularly wasting good bandwidth to download the same files over and over again, using a repository manager to keep a local cache is going to save you a good deal of bandwidth. Even for smaller organizations with limited budgets for connectivity and IT operations, having to deal with a set of developers maxing out your connection to the Internet to download the same things over and over again seems backwards.
Running the Maven Central repository is no short order. It ain’t cheap to serve the millions of requests and Terabytes of data required to satisfy the global demand for software artifacts from the Maven Central repository. Something as simple as installing a repository manager at every organization that uses Maven would likely cut the bandwidth requirements for Central by at least half. If you have more than a couple developers using Maven, install a repository manager for the sake of keeping Central available and in business.
How often in the past few years has your business come to a crashing halt because of an outage? Depending on Central for your day to day operations also means that you depend on having Internet connectivity (and on the fact the Central will remain available 24/7). While Sonatype is confident in its ability to keep Central running 24/7, you should take some steps of your own to make sure that your development team isn’t going to be surprised by some network outage on either end. If you have a local repository manager, like Nexus, you can be sure that your builds will continue to work even if you lose connectivity.
So, you’ve moved over to Maven (or maybe Ivy, Ivy reads the same repository), and you now have a whole room full of developers who feel empowered to add or remove dependencies and experiment with new frameworks. We’ve all seen this. We’ve all worked in places with a developer who might be more interested in experimenting than in working. It is unfortunate to say so, but there are often times when an architect, or an architecture group needs to establish some baseline standards which are going to be used in an organization. Nexus provides this level of control. If you need more oversight over the artifacts that are making it into your organization, take a look at Nexus. Without a repository manager, you are going to have little control over what dependencies are going to be used by your development team.
How do you deal with that one-off JAR from a vendor that is not open source, and not available on the Maven Central repository? You need to deploy these artifacts to a repository and configure your Maven instance to read from that repository. Instead of hand-crafting some POMs, download Nexus and take the two or three minutes it is going to take to get your hands on a tool that can create such a repository from 3rd-party artifacts. Nexus provides an intuitive upload form that you can use to upload any random free-floating JAR that finds its way into your project’s dependencies.
Many organizations require every developer to checkout and build the entire system from source simply because they have no good way of sharing internal JARs from a build. You can solve a problem like this by splitting projects up and using Nexus as an internal repository to host internal dependencies.
For example, consider a company that has 30 developers split into three groups of 10, each group focused on a different part of the system. Without an easy way to share internal dependencies, a group like this is forced either to create an ad hoc file-system-based repository or to build the system in its entirety so that dependencies are installed in every developer’s local repository.
The alternative is to separate the projects into different modules that all have dependencies on artifacts hosted by an internal Nexus repository. Once you’ve done this, groups can collaborate by exchanging compiled snapshot and release artifacts via Nexus. In other words, you don’t need to ask every developer to checkout a massive multi-module project that includes the entire organization’s code. Each group within the organization can deploy snapshots and artifacts to a local Nexus instance, and each group can maintain a project structure which includes only the projects it is responsible for.
If you are an open source project, or if you release software to the public, Nexus can be the tool you use to serve artifacts to external users. Think about it this way… When was the last time you cut a release for your software project? Assuming it wasn’t deployed to a Maven repository, you likely had to write some scripts to package the contents of the release, maybe someone special had to sign the release with a super-secret cryptographic key. Then, you had to upload it to some web server, and then make sure that the pages that describe the upload were themselves updated. Lots of needless complexity…
If you were using something like Nexus, which can be configured to expose a hosted repository to the outside world, you could use the packaging and assembly capabilities of Maven and the structure of the Maven repository to make a release that is more easily consumed. And, this isn’t just for JAR files and Java web applications; Maven repositories can host any kind of artifact. Nexus, and Maven repositories in general, define a known structure for releases. If you are writing some Java library, publishing it to your own Nexus instance serving a public repository will make it easier for people to start using your code right away.