But the good news is, with a Nexus repository manager you don’t need to worry about this ever again.

This video gives a quick overview of the benefits of using a Nexus to proxy Maven Central. It also goes over how to store third party libraries, and host artifacts.

Watch the video below:

While Maven Central contains a huge number of libraries, there are still some pretty important things missing. Anything covered by a non-open-source license, like the Oracle JDBC drivers or anything proprietary, isn’t going to be made available from the Maven Central repository. Very often there are going to be commercial libraries that you will need to download and install in a third party repository. While this works, it requires some manual work to upload the artifact.

Vendors and Repository Management

When your vendors embrace repository management, there’s no reason why you would have to manually install any third party JARs in your corporate repository. Instead, vendors who need to provide binaries to customers would provide them via authenticated public repositories. These vendor-run repositories, protected by authentication credentials, would allow customers to synchronize local, corporate repository managers with commercial software vendors. This would allow vendors to capitalize on a new, “always connected” model for software delivery.

Now, the situation for the customer is simple. Once they set up an authenticated proxy repository to connect to a vendor’s repository, the vendor can deliver new updates and software directly to a customer’s repository.

The situation for the vendor is equally straightforward.  Instead of having to send the customer a packaged set of binaries, they simply tell the customer to update a version number in a dependency. The build will then interrogate the customer’s repository and then automatically download the repository from the vendor.

Both the customer and the vendor have fewer moving parts to worry about, and the task of delivering software becomes very simple.

The vendor receives another benefit from this setup. They are now able to keep track of which customers had requested which artifacts. The vendor can control which artifacts or features of a product suite a customer has access to, and they could use the repository manager as a way to enforce licensing or provide metered, on-demand access to software components.

Partners and Repository Management

In today’s increasingly connected world, it is very common for one company to provide an API for partners. Sites like Twitter and Google provide APIs for the general public, and other companies provide partner-specific APIs for collaboration. If you provide an API for a partner company, you can expose libraries and interfaces using a public-facing, authenticated repository.

Suppose that you work at a financial institution that needs to partner with another financial institution. The two institutions have agreed to collaborate with one another using a simple set of REST services. While these REST services are very well documented, you also want to make sure that your partner is invoking these REST services according to a set of standards. To make it easier to consume these services, you’ve created a simple client library for your partner.

To make it even easier for your partners to use this library, you’ve published versions of this library to a public-facing, authenticated repository. Using the security features of a modern repository manager, you can create partner-specific library versions and limit access to just the intended recipients. You can also maintain detailed audits of when a particular API was delivered to a particular partner.

As more and more organizations start to adopt the best practice of running a repository manager, these same organizations will be creating ad-hoc, private relationships to emulate the ease of Maven Central for a corporate environment. Partners, vendors, and consortia of companies will create repositories to facilitate code sharing and cooperation.

The following diagram shows the process of pushing code to production and automating a deployment:

This post will first discuss production deployments by setting up a hypothetical example. Assume that your organization runs a fairly complex application that consists of a few back office systems, a CRM system, and a web application. When your company needs to deploy one of these systems to production, the result is a highly orchestrated symphony of activity. Servers need to be taken offline in a coordinated manner across a distributed network of machines. Downtime needs to be planned and communicated to the right individuals, and backups need to be created before any new code is pushed to a production system.

In other words, any time you need to push new code to production, it is a real challenge to make sure that everyone is coordinating in just the right way. A few days before a production deployment, the development team freezes a particular branch and tags a release. This release is then installed in a QA environment. The QA team tests the release candidate, and if all goes well, this release is then deployed to production.

Without a repository manager, your operations teams has to know how to checkout a release tag from SCM, they have to run the entire build to generate a few binary artifacts, and then they need to write some scripts to automate a deployment to production.

With a repository manager, you can publish a release candidate binary to a hosted repository. This release candidate binary can then be used by a series of deployment scripts (or a tool like ControlTier or Puppet). You can have a deployment script that will publish the deployment to a QA environment, and then you can have a deployment script that takes the same, certified binary and publishes it to production.

The main difference between these two approaches is that the second approach adds some isolation between the SCM system and the deployment script. If your production deployment depends directly on your build, you have to recompile and repackage your entire system every time you do a deployment. This is often a challenge because the people that run the build system for deployment are seldom the same engineers that develop your system. If your operations team has to check out source code from an SCM just to build a production network, you are introducing some risk into your process.

Instead, use the repository manager as a way to share binaries with operations. If you are deploying applications to QA and production, having to rebuild an entire system from SCM just to deploy a system to an environment is an unnecessary risk. Instead of certifying tags in an SCM, your QA testers should be certifying binaries. This way you can be certain that the systems you are deploying to production have been tested.

Caching artifacts locally

The first, and most obvious, benefit is that a repository manager will proxy and cache artifacts from a remote repository. If you use Maven or another tool that can download artifacts from Maven Central, you have probably had the experience of checking out a large build from source control and running it, only to have to wait for minutes while the build downloads dependencies from Maven Central.  An even bigger frustration than that, if your connection to the internet is tenuous, or if Central happens to be unavailable for whatever reason, you cannot build your code.

With a repository manager, downloading your dependencies takes much less time and your builds don’t rely on internet access. Unless this is the first time building a particular project, all of the artifacts your build uses are going to be cached at the repository manager. Instead of waiting for artifacts to be downloaded over the public internet, your build will download artifacts from a local server. Since you avoid the public internet, this process is sped up significantly. The build that once took 15 minutes to download dependencies will now take less than a minute to download everything it needs.

Get those JARs out of Subversion

The Oracle JDBC driver, a proprietary JAR from a vendor, is the kind of one-off, third party library that is not going to made available on a public repository. Without a repository, the most obvious solution is to just check these JARs into source control and store them right next to your code. When you run your build, branch your project, and release your code you are just passing around these binaries as a part of your project. While this approach does work, you are overloading the source control system to perform a task it wasn’t designed for.

While Subversion, and many other modern SCM tools, will gladly version binaries, you are storing a static, unchanging artifact in source control. Every time you checkout out source control, you are checking out binaries, and if you are unlucky enough to work somewhere that stores all libraries in source control, you will often be asked to check out a large repository of JARs. Your SCM is going to carefully keep track of changes and version files that will never change.

This is both inefficient and unnecessary. If you use a repository manager, you can upload third party libraries to a third party repository that stores artifacts on the repository manager. Then you can mix these third party libraries into a public repository group that will combine the contents of public repositories with your own repositories. In other words, you can declare a dependency on a custom, manually uploaded third party JAR as easily as you would declare a dependency on a library stored in Maven Central. Don’t store binaries in source control, use a repository manager instead.

Collaboration

Collaboration is best illustrated with a hypothetical organization. Imagine you work at an organization with three large development groups of about 30 developers. There is an eCommerce group, which is responsible for writing systems that interact with banks and service providers like PayPal. There is a CRM group, which has the unenviable job of merging two disparate CRM solutions from Peoplesoft and Oracle and wrapping those systems in an easy to use Java API. Then there is a third group, the web applications group, which has the primary responsibility for wrapping these two back office systems in a slick web interface. These relationships are captured in the following diagram:

Imagine that the eCommerce group and the CRM group have to assemble the entire external API into a single project: ecommerce-api and crm-api. These APIs contain all of the logic required to connect to a set of internal services hosted by each group. As the eCommerce group and CRM groups innovate and offer new services, they will cut releases of these new APIs and publish those releases to the repository manager.

When the web applications group is ready to start using a new version of the eCommerce or CRM API they can simply define a dependency on a version of this artifact. The build for the web applications group will then download the appropriate version of the eCommerce of CRM API from the corporate repository manager.

In this way, the repository manager is a central collaboration point for difference groups within the same company. Without the use a repository manager, you will often see disparate groups forced to check each others code out of SCM and build it from scratch just to generate client libraries. In the organization that has embraced repository management, these libraries are published as binaries for clients (in this case other workgroups) to consume from the repository manager.

When you collaborate using the SCM, it is very difficult to scale. Every workgroup is forced to use the same set of tools for build management and you will very often see the entire IT operation having to synchronize releases. When you share build artifacts using the repository manager, you decouple workgroups from one another and allow your internal teams to collaborate using a more adaptive, open-source model.

If the eCommerce group needs to innovate, they can do so without affecting the source code of the web applications group. They can publish new releases to the repository manager, and the web applications group can decide when and how they are going to consume these releases by changing the version of a dependency in a build.

When you collaborate using the SCM, all of your workgroups are joined at the hip by a common codebase. When you use a repository manager you allow different workgroups to innovate and create at their own pace.

In next week’s posts: Continuous Deployment and Integration

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.

Repository Management: The Big Picture

Compare the diagram shown above with the diagram shown below. In the next few posts, I am going to emphasize the specific benefits of using a repository manager. Specifically, I’m going to talk about:

• How a repository manager changes the development cycle
• How continuous integration is used to continuously publish internal build artifacts
• How a repository manager simplifies the process of building and deploying systems to production
• How a repository manager can act as a gateway between vendors and external partners

When you don’t use a Repository Manager

Before I get started on the benefits of repository management, I want to talk about the realities you face when you don’t use a repository manager. Here are some common anti-patterns when you don’t use a repository manager:

• All of your developers download artifacts directly from public repositories. A new developer starts on a Monday. That developer will spend an hour downloading a massive library of dependencies from Maven Central. Worse, if Maven Central happens to be down that day, they will be out of luck entirely.
• Proprietary or Vendors libraries are passed around, from developer to developer. If you don’t use a repository manager, how do you distribute the Oracle JDBC driver? Maybe you place it in a shared file system and tell people to download it and install it in ~/.m2/repository. More likely, developers just pass this JAR around as an email attachment with some ad-hoc instructions.
• JARs are checked into source control. If you don’t use a tool like Maven, which knows how to download artifacts from a remote repository, you might be following the very common pattern of checking binary dependencies and libraries into source control. I’ve seen many instances of companies creating ad-hoc JAR repositories and checking these repositories into source control, only to version and branch these static binary files with every release.
• The source control repository is used to store everything from source code to binary builds. Because there is no repository designed to store binaries, developers start to use tools like Subversion to keep track of binaries. As time passes, the Subversion repository becomes an ad-hoc file system for files that have no business in an SCM.
• The continuous integration server depends on public repositories. When you change your build or add a new dependency, your CI system downloads dependencies from the public repo. It depends on the availability of this public resource to run builds.
• Production deployments have to run the entire build, from start to finish, to generate binaries for deployment. When a build is tested and then ultimately pushed to production, the build and deployment scripts checkout source code, run the build, and deploy the resulting binaries to production systems.
• Sharing source code with external partners means granting them access to your SCM. Since there is no established mechanism for publishing source or binary artifacts, the only way to share code with partners is to either send an archive of your source, or provide them with direct access to your SCM.

The general theme in all of these anti-patterns is that either your systems depend on public resources, or they all depend on the SCM system as a central collaboration point. In the next few posts, I’m going to detail how using a repository manager provides a solution for each of these issues. I’ll go into why each of these anti-patterns is a bad idea, and how you can use Maven, Nexus, and Hudson together to solve these problems and create a more efficient software development effort.

Stay tuned for the next post: Caching and Collaborating.

There are a few things to consider.  Below is just a few differences to keep in mind and help you make the best decision.

Use Nexus if you are new to Repository Management

 Download a copy of Nexus and experiment with hosted and proxy repositories.  You should get a sense of how Maven Settings are configured to retrieve artifacts from a single Repository Group, and you should download a copy of the free Nexus book – Repository Management with Nexus.  Once you’ve familiarized yourself with Nexus, you can easily upgrade to Nexus Professional.

…if you are looking for more stability and control

 If you depend directly on public repositories such as the Central Maven repository or the various repositories maintained by organizations like Codehaus or the Apache Software Foundation, you rely on these servers to be available to your developers 100% of the time.  If a public repository goes down for maintenance, so does your development process.  With a local proxy of Maven artifacts, you buy yourself a stable, isolated build.  Even if a public repository becomes unavailable, you will still be able to build your software against artifacts cached in your own Nexus installation.

Use Nexus Professional if you are looking for professional support

When you purchase Nexus Professional, you are purchasing one year of support from the team that created the industry-standard in repository management.  With Nexus Professional, you not only get a capable repository manager, you get the peace of mind that help is just a phone call away.  Sonatype also offers an array of training, implementation and migration services for organizations looking for an extra level of assistance. 

…if you need a repository manager that can support release and quality assurance decisions

Nexus Professional’s Staging Suite can track the status of a software release and make sure that different decision-makers are notified and supported during a software release. When you start using Nexus Professional your operations, quality assurance, and development teams can use the repository manager as a central point of collaboration.

…if you develop software for an Open Source project

Are you developing an open source project?  If so, most open source projects qualify for a free Nexus Professional license.  Sonatype is very committed to supporting the development of quality open source and this is our way of giving back to the community.

These factors are just scratching the surface of what Nexus and Nexus Professional are capable of, but will get you on the right track when deciding what Repository Manager makes the most sense for you.

Download Nexus:

http://nexus.sonatype.org

Download Nexus Professional:

http://www.sonatype.com/products/nexus

Whenever an artifact is downloaded from a proxy repository, it is automatically cached locally and used to serve subsequent requests. Nexus will continue to serve the artifact until it expires based on the configuration (release artifact typically never expire).

When new artifacts are being requested that Nexus has never seen before, it will look in the proxies to locate it (this behavior can be optimized with routing rules). If the remote request times out, Nexus by default will check two more times before giving up. This is usually enough to handle transient network glitches. If however, the repository is down for an extended period of time, all these retries can back up the connections and slow down over all performance. This is where the auto block comes in.

Whenever Nexus detects a connection is timing out, or receives repeated failures from the remote (for example 500 errors), it will mark this repository as unavailable. All subsequent requests to this proxy will be served from the local cache only. In almost all cases, this is sufficient for your builds to continue unaffected.

Once a repository is marked unavailable, a thread is spawned to proactively monitor its status. In this first release, we wanted to make this feature easy to use and not introduce too many confusing configuration options. We chose a fibinaci type of behavior as the best way to monitor the remote, balancing responsiveness and not pounding the remote with repeated requests at the same time (since we deal with constant abuse of Central, we are sensitive to making Nexus a good repository citizen). We start with a delay of 10 seconds before rechecking the remote, then it will check again in 20,30,50,80,130 seconds, each time adding the delay of the two previous checks. Obviously the administrator can force a proxy to be available again at any time.

In the Nexus server configuration panel, it is possible to define an email address that should be notified of system events. The autoblock feature uses this address to notify of remote repository status changes. To avoid spamming the user for connections that may be flakey, we won’t notify until two retries have failed (ie 30 seconds + the 3 attempts that triggered the blockage). Once the repo is back up, the administrator is also notified.

Nexus monitors the status of a repository by issuing HEAD and GET requests against the root url of the repository. Some systems may not respond correctly to this request, rendering the monitoring ineffective. If you have this type of repository defined, or have a known flaky connection, you may disable the auto blocking feature in the proxy configuration.

In this issue, you can also learn more about Sonatype’s instructor-led online training courses covering Maven and the design of efficient software development infrastructure.  These classes are led by world-class experts in the field and have become the premier source of education for companies deploying Maven-based infrastructure.

To continue reading, click here.

Historically the JBoss and Java.net repositories have been painful for Maven users. The reasons for this pain differed in each case, but overall these repositories have affected a large section of the community because of the popularity of the artifacts they contain.

The JBoss repository generally had decent metadata and release practices.  The major concern in this repo was that the single repository contained artifacts in the following categories: 1) JBoss original artifacts 2) Copies of artifacts from other repositories 3) Artifacts with the same coordinates as artifacts in another repository, but that had been patched or otherwise altered

Ideally the repository should have contained only artifacts in category 1. Category 3 is what caused the most pain, because as soon as you pulled some artifacts from the JBoss repo, you potentially could get “polluted” with these altered artifacts.

We worked with the JBoss team to develop tools that could scan the repository, and categorize all the artifacts into the categories described above. Using that information, we where able to separate them into unique repositories in the new Nexus Pro repo, meaning now you can select which artifacts you want to include based on the url you use. Nexus’ ability to logically group repositories allows JBoss to merge these now separated repos back into a view that matches the old repo, making the migration transparent for existing users.

The problem with the java.net repo is more complicated. In addition to all of the problems described above, this repository suffers from a lack of oversight and quality. We found thousands of artifacts that referred to repositories that no longer existed, that contained snapshot dependencies, that weren’t in the proper folders, and so on. This problem has taken one of our developers almost a month to sort out, but it’s finally just about done. These artifacts will be synced into Central, and we are working with Oracle to prepare a Nexus Pro instance that can be the deployment location for these projects going forward.

In addition to the repository cleanup, the JBoss (and soon java.net) projects are now able to use the Staging and Promotion tools in Nexus Pro that are used in many other OSS forges like Apache, Codehaus, Scala-tools, and Terracotta. This allows developers to stage a release, have automated quality checks occur, and perform their voting and validation phase before promoting the artifacts to the public release repository. This process makes it dead simple to ensure that the basic quality of the releases is maintained.  This helps the entire community, which is why we make Nexus Pro available to OSS projects for free.

For projects that are too small, or otherwise don’t want to host their own instance of Nexus Pro, we maintain an instance at http://oss.sonatype.org.  Here, any OSS project can sign up (http://nexus.sonatype.org/oss-repository-hosting.html) and gain all the benefits of a managed repository, including dedicated Sonatype assistance with their builds. We have almost 400 projects using this instance, including Amazon Web Tools, Google App Engine, Google Inject, Jetty, and many more. Users of this system are able to get their releases published to Central in less than an hour, once they are configured to pass the automated quality checks.  It’s never been easier or faster for projects to release their artifacts to Central.

Based on the outstanding adoption rate of our tools in the community, it is clear that project development teams of all sizes really want to provide a quality product for their users in the form of clean artifacts and metadata. This just wasn’t easy to do in the past. Sonatype is making it a priority to empower these projects by providing first class tools and self-serve access to Central.

“Nexus is a repository manager. It allows you to proxy, collect, and manage your dependencies so that you are not constantly juggling a collection of JARs. It makes it easy to distribute your software. Internally, you configure your build to publish artifacts to Nexus and they then become available to other developers. You get the benefits of having your own ‘central’, and there is no easier way to collaborate.”

Someone who doesn’t program every day nods, feigns approval; “That sounds very interesting”, but I am still skeptical that I got the message across. I’ll usually resort to an assembly line analogy; “Think of Nexus as an assembly line, it provides a context for collaboration.” But, still, there is a lack of shared context. If you are a programmer, my previous explanation was likely clear. If you are not a programmer, you’ll have questions. What is ‘central’? What is a ‘JAR’? What am I proxying? Instead of attempting to explain Nexus in a paragraph, let’s try to set up some background.

What is Nexus?

Nexus is a repository manager, it stores “artifacts”, but before jumping into abstractions, let’s start with a description of software development. We’ll begin with a simple description of what software development involves, and, for the purposes of this article, we’re going to discuss Enterprise Java Development. Before I can tell you what Nexus does, we have to answer the following question…

How is Software Developed?

Use a web site like the New York Times or even something as deceptively simple as Google, and it might be easy to think that the effort takes a handful of developers, some graphics designers, and a few weeks of effort. Think again.  For a system of any significance, we’re usually talking about tens to hundreds of developers (sometimes thousands of developers) split into different groups each with a distinct focus. For example, think about a large, international bank. Such an organization will likely employ thousands of developers spread throughout the world. There might be a hundred developers in San Francisco focused on web development, with tens of developers in New York focused on market feed and data integration. Maybe there is a group that focuses on back office operations in Toronto, and a group dedicated to international clients in Dubai, and another development group in Bangalore.

The point here is that modern software development is often distributed, and the largest systems involve hundreds of developers all trying to collaborate on a single enterprise system. “Big software” can involve thousands of developers and today’s CTOs and CIOs realize that the way to remain agile, the way to innovate, is to adopt best practices from the open source community.    Open source projects like the Linux Kernel or open source communities like the Apache Software Foundation are proof that thousands of developers can collaborate on complex systems if they are provided with efficient infrastructure and a shared set of assumptions about how software is developed.    While it is often difficult to import the culture of open source into a corporation, it is fairly easy to standardize on the same tools, the same “efficient” infrastructure which allows a large, ad hoc group of developers to collaborate.

Efficient Development Infrastructure

Source control systems, issue trackers, mailing lists, continuous integration servers, wikis, integrated development environment, and repository managers; when you start a new open source project one of the first things you decide upon is what you are going to use for each of these components.    Let’s go through each of these components and discuss the various choices that are available:

• Source Control Systems: This is the service that is going to track your code, the code that is eventually transformed into a working system.  So, if you are developing web sites, the code is likely a primary artifact right next to content and design.  Source control systems are an established piece of infrastructure and programmers have been using them for decades.

• Mailing Lists: While this might seem too simple to be considered a part of development infrastructure, it is often the most essential and most basic piece of infrastructure.   Efficient development teams tend to share just about everything technical on a shared mailing list.  Each focused development team has a mailing list, and the discussions are archived for future reference.  As the team’s composition evolves over time, this shared conversation can be an important record for bug fixes and institutional knowledge about an application.  Mailing lists, like source control, have been around for decades.

• Issue Trackers: Your team will need a place to store tasks and bug reports, and they will also need to have a way to plan what goes into the next software release.   A good issue tracker provides a programmer with a way to customize and filter the list of issues by project or by person.   A great issue tracker can double as both a collaboration tool and as a simple productivity dashboard for programmers.   Issue trackers have been used by open source projects for more than a decade, but modern issue trackers (like JIRA) are still developing features which redefine the category.

• Continuous Integration Servers: Think of an automated “robot”, sitting in a room next to your developers constantly waiting for code to change.   When code changes, this automated “robot” brings those changes on to his system and performs a software build.   If the build fails or if tests fail, all of the developers are immediately notified of the failure, and everyone drops everything to make sure that problems are quickly addressed.  The principle behind continuous integration is that the sooner a bug is found, the easier it is to fix.   If your cubemate checks in some bad code, there is less of a chance of it going unnoticed if there is a system constantly running and testing the code as it is changing.  Before the age of continuous integration servers, programmers and developers might only perform whole system builds and integrations once every few weeks or months during a software release. While this might seem like an obvious part of software development, continuous integration servers have only become standard in the last five years.

• Wikis: If you used Wikipedia, you know what a Wiki is.   It is a shared website that is easy to edit and open to any participant.   Most internal development teams have a Wiki for collaboration that doesn’t make sense to conduct on a mailing list.   The net effect of having a Wiki for a development team is that the team tends to send less Word or Excel attachments around on the mailing list.   If there is some specification that needs to be developed, it is normal for people to do so on a Wiki.  The Apache Software Foundation only started allowing for an open Wiki six years ago, and it is has only recently become something standard in most internal development environments.

• Integrated Development Environments (IDEs): This is the primary tool that developers use every day.   If you see a programmer “coding”, she is very likely staring at a GUI tool, like Eclipse or IntelliJ, which contains tools that make it very easy to write code.

Repository Managers

This brings us to the final component of efficient development infrastructure – repository managers.

Repository Managers: You can think of a repository like you would think of a library.   It is a server that stores and retrieves files, which we refer to as artifacts.   When you write a piece of software, you are often depending on external libraries.   If you are developing a system to send a rocket into space, you might depend on a library that provides functions to calculate the effects of gravity.   If you are building a web site, you’ll likely use a framework designed to serve web sites.

In Java, these libraries are stored in binary files called JARs, and if you are working on a complex system, you might require hundreds of external libraries in an application.    The primary use of a repository manager is to proxy and cache artifacts from “external” repositories.     Your organization uses open source libraries, and when your build needs them it will automatically query a local repository manager.   If that local repository manager does not have that particular artifact, it will retrieve it from an external repository server and cache it for later use.  (Think of how an academic, Interlibrary Loan system works.   Ask a librarian for a rare book.  If he doesn’t have it, he will likely call up another library and have the book sent over.)

“Central” refers to the “Central Maven Repository”, you can think of “central” as the global repository manager that stores all open source components.   “Central” has millions of users throughout the world, and it is fed by thousands for open source projects.  It is the modern-day “Library of Alexandria” for open source components, and it greatly reduces the work required to distribute software to millions of developers.   If you have something to share with the world, put it on “central”, distribute the coordinates, and in minutes everyone should have a copy.

Before the advent of “central”, users would have to manually update dependencies, and open source projects would have to try to get the word out so people knew about a software release.  In 2010, releasing a new open source component to the Central Maven repository is a non-event.   All a developer needs to do is publish to “central”; the rest is automatic.  If a developer is using a repository manager, they can even configure the tool to notify them of all new releases.    The “central” Maven repository manager is the central fabric of collaboration, and over the past eight years, it has changed the way that software is distributed and developed.

While “central” brings efficiency to an entire world of software developers, running an internal repository manager brings efficient collaboration between your developers and teams.   If one team develops a library used by another team, they can use an internal repository manager to distribute software releases internally.  If your development teams are delivering applications to an operations group for deployment, they can use a repository manager as a way to share final products.

While the open source world has standardized on repository managers in the past three years, most organizations are still at the beginning of the adoption curve.   The organizations that have adopted a repository manager understand the benefits, and understand that development without one would be a process fraught with inefficiency.   I’ll predict that, within three years time, most organizations will be running a local repository manager called Nexus.  It is as essential a technology as source control.

What is Nexus? for the Non-programmer

So, “what is Nexus?”  for the Non-programmer.    If it still doesn’t make any sense after reading this post, think of it as a library.   You can ask it for “artifacts”, it will store and retrieve them and assign a standard coordinate system to the artifacts it stores.   If you are developing software, having this facility available allows you to catalog and store your own artifacts using the same “numbering” system that the library uses.   When a group develops a new system or a library, they submit it to the repository manager.   Other groups then have a standard way to access these libraries.   This standard for cataloging and addressing files brings efficiency.

Think about how difficult it would be if books didn’t have ISBN numbers, or if libraries didn’t have a filing system like the Dewey Decimal system.  You wouldn’t be able to search for books, you wouldn’t be able to quickly locate a book on Amazon.   The repository manager is that “library”.