Repository Management with Nexus


2.6. Reasons to Use a Repository Manager

Here are a few reasons why using a repository manager is 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 have used 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.

2.6.1. Speed Up Your Builds

When you run your multimodule 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 snapshot 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. We have found complex builds to cut build time by up to 75 percent 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.

2.6.2. Save Bandwidth

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.

2.6.3. Ease the Burden on Central

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.

2.6.4. Gain Predictability and Scalability

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.

2.6.5. Control and Audit Dependencies and Releases

So, you’ve moved over to Maven (or maybe Ivy that 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 that 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.

2.6.6. Deploy Third-Party Artifacts

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 handcrafting 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 third-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.

2.6.7. Collaborate with Internal Repositories

Many organizations require every developer to check out 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 dividing projects 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 with 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 filesystem-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 check out a massive multimodule 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.

2.6.8. Distribute with Public Repositories

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. 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.