I'm surprised at the number of organizations out there that use a tool that depends on the Maven Repository, but haven't yet adopted a repository manager. It could be that no one has made the argument for it. No one has stood up on a platform and called people's attention to the benefits of using a repository manager. The responses I've always heard from organizations that don't use a Maven repository manager are along the lines of: "We don't need to get that complex...," or "Central's fine, we don't need to host the entire repository locally..."
Needless to say, there are a few misconceptions floating around about what a good Maven repository "is". First, it isn't complex to set up. It will take you a few minutes to download and install Nexus, and we've gone out of our way to make it as easy and non-invasive as possible. Second, a repository manager which can cache a remote repository doesn't cache the entire thing. A good repository manager caches only what you use on an as-needed basis. Here are nine more reasons for people who might be on the fence about a repository manager.
#9 - Speedier Builds
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.
#8 - Your own bandwidth savings...
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.
#7 - Saving the bandwidth of Central Maven Repositories
Maybe an appeal to altruism and civic, public duty might help. Running the Central Maven 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 in business.
#6 - Predictability and Stability
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 we're confident in our ability to keep Central running 24/7, you should take some steps of your own to make sure that your development teams 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.
#5 - Control and Auditing
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 just 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.
#4 - Ability to Deploy 3rd-party Artifacts
You wish you worked with an open source database like MySQL or Postgres, but your organization has different requirements and a long support contract with Oracle. Because of this, you have a series of JAR files which are not available in any publicly accessible Maven 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 free, capable tool that can create such a repository from 3rd-party artifacts. Nexus provides an intuitive upload form which you can use to upload any random free-floating JAR that finds its way into your project's dependencies.
#3 - Ability to Host Internal Repositories
Great, you are using Maven and everybody has an efficient build that builds every piece of code required from scratch. This was working very well for a year, but then the system became so massive, programmers complain that the build takes too long to run. 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 filesystem-based repository or to build the entire 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 a 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.
At a macroscopic level, the public Maven repository and the establishment of a strict regime of project indentifiers serve as the foundation for cross-project collaboration in the open source space. (Didn't that sound important and "august"?)
#2 - Ability to Host 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. And, this isn't just for JAR files and Java web applications; Maven repositories can host any kind of artifact (in fact, I'm thinking about using a Maven repository structure to distribute user documentation and video content). 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.
#1 - It is so easy... no really, it is easy...
I can just hear it, right now throughout the land. There is a morning Scrum meeting or a weekly software status event. Some junior programmer sheepishly raises his or her hand and says, "Can we install a repository manager like Nexus? I think it would speed everything up dramatically." The development manager, stressed for time and money, hears the words "install" and "software" and fires back that they don't have time for infrastructure work because it isn't "requirements driven". (I've seen it happen.)
What this manager doesn't know is that the installation of Nexus on a shared machine and the configuration of the subsequent system service would likely take less than ten minutes. In fact, you can read the installation instructions in the free Maven book. It really is easy to install Nexus. I've had some practice, but I think anyone who knows how to operate a web browser could get the job done in a few minutes.
