Two weeks ago, all Scala projects required a little bit of extra configuration to point to a custom repository for Scala artifacts hosted at scala-tools.org. Today, Scala artifacts are now available directly from Central. The contents of scala-tools.org are now integrated into the Sonatype OSS repository hosting service, and other projects have started to publish artifacts Central.

The Scala community will see immediate benefits from this move. There are no more extra repositories to configure. It just got incrementally easier to use Scala. If you are new to Scala, you don’t need to reconfigure your repository manager to proxy another remote repository. The community will benefit from Sonatype’s continued investment in the infrastructure that runs Central: a cluster of machines in both the US and the EU continuously monitored by a dynamic DNS server that can reroute traffic instantly in the event of downtime.

How did this happen? Joshua Suereth, David Bernard, and Derek Chen-Becker provided the bulk of the administrative work, and they recently decided to decommision this server and transition repository hosting to the free Sonatype OSS service. Here’s the announcement by Joshua Suereth to the user forums on scala-lang.org on January 17th:

Scala-tools.org is going down and not accepting any new OSS projects. For those of us who wish to continue release software, I recommend migrating over to Sonatype. They put a few (good practice) limitations on contributions, but scala-tools.org would have done the same before long anyway. The benefit of Sonatype hosting is that your projects will make it onto the maven-central repository and benefit from the myriads of mirrors. Here’s the link for how to get started contacting Sonatype: http://nexus.sonatype.org/oss-repository-hosting.html

Publishing Your Scala Project to Central via Sonatype OSS

If you maintain a project that previously published to the scala-tools.org repository, here are three resources that provide guidance for Scala developers looking to publish Scala artifacts to Central:

• Publishing artifacts to Sonatype instruction written by Joshua Suereth on publishing to Sonatype OSS
• Publishing SBT Projects to Sonatype OSS from Cake Solution’s Specs2 Spring Project
• PublishToSonatype.scala some Scala code from Paul Phillips to automate the process of publishing artifacts to Sonatype’s OSS

“Wait, that’s how Central works?”

There’s something so automatic about dependency management in Maven that it often takes people a few months to understand exactly where those JAR files are coming from. In an 8 hour Maven class, I get to dependencies in the third hour, and after describing Central, what it is was like before Central, how metadata is stored in a repository alongside binaries, transitive dependencies, etc…. it all falls into place, and people realize that this simple thing they’ve grown accustomed to is only easy because of a ten year effort to refine the model, the creation of a support structure for source forges at places like Oracle and Google, and a constant investment in infrastructure.

On the one hand, it’s a great success that Central is, for the most part, an invisible utility that supports developers.  On the other hand, it’s the kind of thing that people can start to take for granted very easily.

For example, a few months ago I spoke to someone who worked in an environment disconnected from the internet for security reasons.   This individual was talking about how limiting it was to have to download JARs from open source projects manually and assemble them in a project.   His words were: “It’s like programming Java in 2001 again.”

How can you help?

Imagine millions of developer spread all over the world: different time zones, different applications, but they all hit the same service: Central.    Some regions have more developers than others so we certainly see peaks in usage throughout the day, but in general, Central’s serving thousands of files throughout the world at any given time during the day.

Maybe someone just installed Maven for the first time, or maybe they blew away a local repository, with numbers like these we see a world that has a constant appetite for artifacts.   It isn’t a problem for Central, and I’m not writing this because Central is falling down on the job. Central can handle it, but it certainly isn’t the most efficient way to support millions developers.  It isn’t a good use of network bandwidth, and it isn’t a good use of energy to constantly cart around the same static JARs over and over and over again when the solution is so easy.

If everyone who used a build tool that interacted with Central adopted a repository manager such as Nexus we’d have a faster, more responsive system.   Central’s maintainers would be focused less on addressing the occasional runaway build and could spend more time and resource on increasing availability and functionality of this essential service.

Broken Builds

The other factor playing into this is that Maven builds only download releases once.   It isn’t like these build tools are repeatedly returning to Central to download release artifacts over and over again.

Well… actually… that isn’t true, we’ve seen some installations of Hudson configured to delete a local repository before every build placing a high load on Central.   Imagine a build that downloads 50 MB of dependencies running once every 5 minutes.  That’s one build consuming ~14 GB a day never mind the time wasted downloading static artifacts. While these broken builds are the exception, they do still show up from time to time.  Central can handle the load, but imagine 1000 of these broken builds running continuously and you can see the challenge.

A Simple Reminder: Please Proxy Central

We’re constantly watching the performance of the system and making sure it stays up and running for an entire world of developers.  If you use a build tool that hits Central whether it is Buildr or Maven or Gradle or Ivy, you can help us by running a Nexus instance.

Even if all of your builds work perfect, running a local Nexus instance helps preserve Central as a public, free resource and it will lead to faster, more responsive builds.

At Sonatype, we want to make synchronizing and publishing your artifacts to Central easier and to improve the quality of repository metadata for everyone at the same time. To facilitate this, we offer a dedicated instance of Sonatype Pro for Nexus at http://oss.sonatype.org specifically to host the artifacts of open source projects. In this post, I talk about the process of creating a repository for your open source projects and publishing artifacts so that they will be available from the Central Repository.

This service has been available since 2009 and includes many projects such as Plexus, Jetty, Google Guice, Spring and Ehcache (Greg wrote about his experience with migrating to oss.sonatype.org). We have tooling in place to make it easy for us to process a larger set of requests, so we invite everyone to use this resource. As of October, 2011, we have over 1,500 projects using this repository on a daily basis.

To get the process started, go here. We’ll setup a release and snapshot repository for your project, along with the appropriate configuration to allow you to use the staging features for your releases. If you have an existing repository somewhere, we can migrate that for you too. We’ll even help you add artifacts to Central that you use, but don’t necessarily own — assuming of course that it doesn’t violate the projects license.

The system allows customizable rules to be run during the staging process, which allows us to automatically check things like valid pgp signatures and correct POM parsing. This will ensure that your users have the best experience possible when using your artifacts, and relieve some of the manual validation on your side — a win for everyone.

On the technical details, this instance gets its network connection via Contegix‘s high availability network, the same one running Central, Codehaus.org and Atlassian.com. New Relic has donated monitoring services to help us monitor and tune this instance of Nexus. Since OSSRH is hosted on the same infrastructure as the Central Repository, we are able to frequently synchronize the repositories.

Next time you need to add a project to the Central Repository, you’ll know how.

While this seems like such a simple idea, the Maven ecosystem hasn’t had a standard way to search the repository for the majority of its history. For much of the last decade there was no reliable way to search for an artifact. In this post, I’m going to review this history and talk about Maven repository search and where we think search is headed. With the release of Nexus OSS 1.9 it is now a good time to summarize the results of Sonatype donation of the Nexus Indexer to the Apache Software Foundation.

In the beginning…

In the beginning there was ibiblio. That’s not entirely true. When Jason van Zyl created the first Maven repository in 2002, there were a number of different servers and mirrors involved, but after a few weeks of migrating between Apache servers, the first incarnation of Central ended up at ibiblio.

If you were depending on the Maven repository back then, you have a good appreciation for how far we’ve come in just a few years. Back then, the bandwidth was terrible and the connections were iffy. It was touch-and-go both in terms of stability but also in terms of process. You can still see some of the echos of the initial effort today in the form of old group IDs. If you are wondering why projects like log4j and commons-lang exist as top-level group IDs it is because the initial artifacts didn’t follow the same strict standards for naming. In 2002 the repository was emerging, and it would take a few years for people to agree on standards and formats.

Maven’s Structure Becomes a Standard

Within a year, people using the Maven repository had come to rely on it as an essential piece of development infrastructure. While Java had been around for almost a decade, no one had created a viable repository structure. There was no way to distribute artifacts between projects, and the Maven repository was created at a critical time in the development of open source Java. As Java really start to take off in the enterprise, as systems grew more complex, and as an explosion of open source Java libraries hit the scene from places like Apache, the Maven repository quickly became the established way to distribute artifacts. There was no going back.

Maven Search: The Dark Ages

Years passed, the format of the repository changed between Maven 1 and Maven 2. As more and more projects started to use Maven or publish to the Maven repository, there was a need to create some sort of search interface to help developers locate artifacts in the repository.

Initial efforts for repository search were disconnected and relied on multiple, independent systems running proprietary analysis on the entire repository. (I know this myself because I took at stab at writing one in 2006.) To search the repository, you had to download the entire repository and run a series of regular jobs to grab changes and update an index. There was no standard search mechanism that would facilitate tool integration, and most people discovered Maven artifacts either by clicking around in a browser or by word-of-mouth.

Earlier Repository Managers and Search

Early repository managers contained independent implementations for search indexing. Early versions of Archiva had an independent index library based on Lucene, and Artifactory relies on a JCR store. While it was clear that repositories were going to play a key role in providing an easy way to search for artifacts by metadata and class name, these earlier approaches still required people maintaining repository managers to download the entire repository and run a time consuming, CPU-intensive process just to create searchable index.

This is where the Nexus Indexer started to come into play.

The Nexus Indexer

When Sonatype created a repository manager, we also aimed to create a standard and sustainable way to search for artifacts. The Nexus Indexer defines a standard format for repositories, but, most important, it defines a portable format that captures information about a repository. This format is what your repository manager downloads from a remote repository, and it is the reason why repository managers like Nexus and Archiva can allow you to browse the contents of a remote repository without downloading “the entire internet”.

Sonatype’s open source repository manager, Nexus, was the first repository manager to define a standard format for a repository index. We didn’t just define a product with a search feature, we set out to define the standard. Using this model, servers like Maven Central and other popular open source forge repositories would periodically index repository contents and present clients with an index. Instead of downloading Terabytes of data from the internet, your Maven client, your IDE, your repository manager could download an optimized index containing all of the metadata about artifacts in the repository.

This innovation also had the effect of offloading the responsibility from your repository manager. If you want to search the repository, you don’t have to set aside a few days for your own instance to crawl Terabytes of data. Maven Central is indexed once, in a central location, and the world saves zillions of CPU cycles because of that fact.

The Nexus Indexer was an immediate success, the index format was created on a weekly schedule on Maven Central. Sonatype carved out the Nexus Indexer as a separate component, released it under a very conservative, BSD-style license, doing all we could to make sure that everyone interacting with the repository could read this format. Very quickly all of the repository managers on the market could both read from and write to a Nexus Index. For example, Archiva now relies on the NexusIndexer, and will likely move to the Maven Indexer.

Donating Nexus Indexer to the Maven Project

As this index format became more widespread through the Maven ecosystem and more generalized for other languages and systems. Sonatype thought it made perfect sense to remove any direct association with Nexus. It was becoming a part of the foundational infrastructure for the community, and, in a decision that might make some executive’s heads spin with disbelief, we donated it to the Maven community. We gave it away.

For something this low-level, this important to the community, it didn’t make any sense for Sonatype to hold on to this resource. The Nexus Indexer is now called the Maven Indexer and the code behind this index is now a part of the Apache Maven project.

At Sonatype, we understand the role we play in supporting the universal infrastructure that enables the world to develop and collaborate. We also understand how important it is to ensure that something as important as the index format be truly open: managed by an active and healthy community, free of difficult licensing questions, and unencumbered by patent concerns.

Next Up: Nexus OSS 1.9, Now with the Maven Index

To complete the circle of our successful transition of the Nexus Indexer to the Apache Maven project, we’re announcing that the next version of Nexus is one of the first projects to incorporate the newly minted Maven Indexer. Stay tuned.

To improve the experience for users in Europe, Sonatype has provisioned a new official repository in the United Kingdom. This is more than a mere mirror of Central, this system is updated in lockstep with the systems here in the US, and is managed and monitored 24×7 by Contegix, the same team watching over the US repositories. The new repository consists of two fully redundant systems running in parallel to provide complete fail-over capacity.

In addition to the new repository, we have taken several steps to improve and further secure Central itself:

• A new system has replaced Central as the inbound processing engine. On this staging system, we can now vet inbound artifacts for quality and other parameters before publishing them to repo1 and Europe. It also serves as a hot standby for the US repository.
• We’ve worked with Contegix to implement additional layered security around the repository machines themselves.
• There is a new Jira project to manage any and all concerns and issues with Central, the Mirrors, Content, etc
• We are working to setup another official Central Repository in Asia soon

The new repository is live at http://uk.maven.org/maven2/ if you’re using a repository manager, just replace references to http://repo1.maven.org/maven2 with the new url. If you’re not, you should be (Whitepapers: Intro to Repository Management / Stages of Repository Adoption), but until you get a repository manager in place, add the following to your settings.xml:

<mirrors> <mirror> <id>uk</id> <mirrorOf>central</mirrorOf> <url>http://uk.maven.org/maven2/</url> </mirror> </mirrors>

Some additional coverage on this topic can be seen at InfoWorld, BusinessWire and InfoQ

Better maven support has been frequently requested on the issue tracker and mailing list, and this is a first step in that direction. In the future, Google will publish GWT releases to maven central as part of the release process.

The GWT 2.0.4 jars currently in the repository include gwt-user, gwt-dev, and gwt-servlet.    To publish these artifacts in the Maven Central repository, Google publishes artifacts to Nexus OSS, the Open Source oss.sonatype.org repository.   You can see the Google-specific repository on this server here.   Releases are staged to this Google repository on oss.sonatype.org and then subsequently released and synchronized to the Maven Central repository.

Configuring the GWT Plugin

To start developing with GWT, take a look at the “Automatic Mode Setup” section on the GWT Maven plugin’s Setup instructions.   Before last week, the only way to develop a GWT application with the latest version of GWT was to download the SDK to your workstation and then use systemPath dependencies or a custom task to publish artifacts to your local repository.    Today, you can just point your Maven project’s pom.xml at the correct version of gwt-servlet and gwt-user and Maven will grab the necessary native libraries from Central.

This doesn’t just make GWT development easier and more straightforward for people already using the tool, it will make it much easier for developers to start using GWT.   When you publish your project’s artifacts to the Maven Central repository you make it easier for people to adopt your technology.   Maven Central is the “dial tone” for most developers, and if you put it on Central, they can access it without having to download an SDK or configure a build system.   Maven Central just works.

Nexus OSS is the fastest, most efficient way to publish artifacts to Maven Central, and Sonatype has made this service available to any open source project that needs to publish artifacts.   If you work with an open source project or a company which publishes open source libraries, read the Sonatype Nexus OSS Repository Guide to get started.

Sonatype is focused on improving the foundational infrastructure which will allow us to improve the quality of artifacts and their accompanying metadata in Maven Central and Maven repositories around the world.  A lot of this is not especially glamorous work and though many people complain about the state of some of the Maven repositories, very few take action.    Here are some of the things Sonatype is doing with Nexus to improve the state of the Maven ecosystem and expand its scope.

Improving the Quality of Public Maven Repositories

Any effort to improve the quality of the Central Maven repository needs to begin with the major feeder repositories.  For years, we have been giving rsync access to many of the organizations with large feeder repositories like Apache and Codehaus.   When we started this effort, we were optimistic that these organizations would take care of their Maven repositories.   We thought that repository maintainers and projects would make sure that all artifacts were signed and that all POMs contained a bare minimum of useful elements such as “license” and “description”.    With hundreds of projects pushing artifacts into their respective repositories on a daily basis, it has become obvious that without some mechanism to guarantee quality, without a well-defined process, the Central Maven repository will contain artifacts and metadata of questionable status.  While the vast majority of artifacts have appropriate PGP signatures and metadata, the fact that a minority of (often very popular) artifacts lack proper dependency definitions or license elements means that we see a steady stream of complaints about the quality of the repository from our users.

These problems can be anything from one project trying to publish another project’s artifacts because they weren’t in Maven Central, incorrect, bad, or missing metadata, missing javadocs or source JARs, to invalid transitive closures.  Whatever the problems are, the overall issue stems from the lack of process surrounding how artifacts are published to our feeder repositories, and how these artifacts are then certified to be published to the Central Maven repository.

Sonatype’s answer to this problem has been to provide tools that can automate the process of repository maintenance for Central’s largest customers – the main feeder repositories.   We’ve provided a solution to the largest of the feeder repositories which allows them to use the Nexus Staging Suite to validate that all release artifacts contain the bare minimum of metadata, javadoc, and a valid PGP signature.    As Ate Douma wrote in Monday’s post about using the Nexus Staging suite to support the Apache Portals project, we’ve supplied a solution that reduces the amount of error-prone, manual work associated with software releases, and we’re going to continue to find ways to address the needs of large, open-source enterprises with Nexus by providing Open Source projects and organizations with a free license and free support.   Here is a list of some of the organizations with large feeder repositories that we are supporting directly:

• The Apache Software Foundation
• Codehaus
• Alfresco
• ExoPlatform
• Glassfish
• Open QA
• Scala-Tools

With all of these organizations and projects using the Nexus Staging Suite, we are confident that the quality and reliability of artifacts and metadata will increase over time.  The PGP signatures provide the security assurances organizations need, and the sources, javadocs and correct POM information like SCM information make for a better developer experience in the IDE.  In M2Eclipse, for example, javadocs and sources can be dynamically retrieved as required and binary dependencies can be materialized to source from from SCM coordinates. This makes contributing patches to an dependent project an order of magnitude easier.

We are also fortunate to be working closely with Atlassian. We have Atlassian Crowd support in Nexus, so Nexus is an ideal fit for Atlassian and for organizations that make use of Atlassian’s compelling products. You can find Atlassian’s Nexus instance here. It’s just another validation point for us that Atlassian sees fit to use our products as part of their daily development. We have a lot of respect for the Atlassian folks, and we’ve standardized our entire development environment on tools like JIRA , Greenhopper, and Confluence.

Decreasing the Time to Reach Maven Central

Many users and projects have complained that it can take a while to get their artifacts in Maven Central so we’re starting to focus on reducing the time to reach Central. The biggest obstacle to automating the process of publishing artifacts to Central is one of quality.   Artifacts would reach central faster if there was a better way to enforce a minimal set of quality standards.  The legacy process involved projects uploading “bundles” to a JIRA project and repository maintainers manually inspecting the bundles to see if they complied with a set of standards.

In the previous section, I described how Nexus is already powering the major feeder repositories for the Central Maven repository.  What we offer projects is described here. Basically we will help you cleanup, and migrate your project’s Maven repository to our hosted infrastructure and help you setup your project POMs to use Nexus’ Staging. Projects are setup with the default staging rules which ensure the presence of PGP signatures, javadocs, sources, and a POM which contains decent information. We provide all the instructions for the setup on the Maven side so there is little work you have to do in order to take advantage of this service.  We are also providing a mechanism by which the standard bundle uploads, typically done via JIRA, can be handled by Nexus. Internally within Nexus the upload bundle is exploded and placed in a staging repository, as would happen if you performed the release against Nexus from your Maven build.  We then apply the same staging rules to ensure quality.

We have already started rewarding projects with good Maven releases by automating their synchronization with Maven Central.   Over time we are going to start enforcing standards for security and quality of metadata.    If you have proper project metadata, PGP signatures, javadocs and sources your artifacts will fly into Central as quickly as possible.  Projects that submit poor Maven releases are going to have a more difficult time getting artifacts into Maven Central.   We’ll start to enforce these standards gradually and we’ll give the community time to adapt.  Any tool that creates bundles for deployment to Central is capable of producing these artifacts. The staging rules don’t care how the releases were constructed. So use whatever tools you like, you’ll just have to pass a minimal set of requirements to make it into the Central repository. Over time this should greatly improve the quality of Maven Central.

Providing Metadata about Repositories

For a long time we have been providing a way, through Nexus, and the stand-alone Nexus Indexer, to produce the Maven repository index.  The repository index contains information about all the artifacts in the given repository including class file information and project identifiers.  It is primarily used as part of IDE integration to help developers find dependencies based on artifact coordinates or class references, like import statements.   Using m2eclipse, all you need to do to add a new dependency is type the name of a class into your code and search the index for matching dependencies.    You can also search the repository index for all of the available Maven archetypes when you are creating a new Eclipse project.    Both of these IDE use cases are possible because of the standard repository index format that was defined as part of the Nexus project.

The Nexus index format is also storing information about the presence of PGP signatures, javadocs, sources, and checksums.   Using Nexus and other tools that can read the Nexus index format, you can aggregate multiple repository indexes together and perform quick searches across multiple public repositories (as well as your own hosted repositories). The Nexus indices from the OSS repositories around the world are proving to be a critical resource, we can tell because it is the most requested item from Maven Central.  Index downloads amounted to 28TB of transfer last month.

Polyglot Component Repositories

The explosion of language choices has transformed the way most developers approach problem solving.   Just four years ago it would have been normal to walk into a corporation and see Java at all levels of the stack.  In 2010, most businesses have started to incorporate multiple languages and hybrid architectures into enterprise systems.   A system designed today might use Ruby on Rails (running under JRuby) to power a web site which interacts with a set of services coded in Java.  Services like Twitter rely on a foundation of Scala code executing on the JVM while other portions of the Twitter architecture use different languages and different technologies where they are most appropriate.

We are a polyglot industry, and while our software enterprises are run on a mixture of different languages, our development tools and build technologies are often locked into a single language or a single technology.   A Ruby application is built using Rake, a Scala application is built using Sake or the Maven Scala plugin, and Java or OSGi applications are built using Maven.   A Ruby library might generate and consume gems while a Java application might generate and consume JAR files.   There is currently no single, consolidated “Tower of Babel” to help developers translate between different types of software artifacts.   We’ve put a lot of effort into making the foundation of Nexus as agnostic as possible about what it is storing, and, because of this, we’re moving to add support for even more artifact types.

Nexus currently supports the two OSGi formats of P2 and OBR and we are just finishing our first draft of RubyGems support.   Polyglot Maven will drive us toward a Polyglot Nexus. As part of the work we’re doing on Polyglot Maven we may find that different scripting language implementations have slightly different requirements for dependency management or provisioning runtimes, and we’ll be ready for that.

Where do we go from here?

Next we’re thinking about ways to make statistics for a given project’s artifacts available to the project’s developers.  We have already implemented user signup in Nexus and we are currently working on project signup as well. What this means is that projects can register with a given groupId, or set of groupIds, and optionally be provisioned a repository which can be operated by a set of users. Once a project registers we will know what slice, or slices, of the statistics they need to see.   Our initial thought is that project statistics, number of downloads should only be made available to the public with the permission of each individual project. Brian and I along with Greg Luck and Dain Sundstrom have been working on a simple statistics mechanism that we hopefully can provide to projects early this year.

At Sonatype, we want to make synchronizing and publishing your artifacts to Central easier both for you and for us, and we want to improve the quality of repository metadata for everyone at the same time. We have set up a dedicated instance of Sonatype Pro for Nexus at http://oss.sonatype.org specifically to host the artifacts of other Open Source projects. In this post, I talk about the process of creating a repository for your open source projects and publishing artifacts so that they will be available from the Central Repository.

This service has been available since 2009 and includes many projects such as Plexus, Jetty, Google Guice, Spring and Ehcache (Greg wrote about his experience with migrating to oss.sonatype.org). We have tooling in place to make it easy for us to process a larger set of requests, so we invite everyone to use this resource. As of October, 2011, we have over 1500 projects using this repository on a daily basis.

To get the process started, go here. We’ll setup a release and snapshot repository for your project, along with the appropriate configuration to allow you to use the staging features for your releases. If you have an existing repository somewhere, we can migrate that for you too.

Since the Sonatype machines are hosted on the same infrastructure as the Central Repository, we are able to synchronize the repositories every hour instead of twice a day.

The system allows customizable rules to be run during the staging process, which allows us to automatically check things like valid pgp signatures and correct POM parsing. This will ensure that your users have the best experience possible when using your artifacts, and relieve some of the manual validation on your side, a win for everyone.

On the technical details, this instance gets its network connection via Contegix‘s high availability network, the same one running Central (and Codehaus.org and Atlassian.com), and New Relic has donated monitoring services to help us monitor and tune this instance of Nexus.

What is a Repository Manager?

• A proxy for remote repositories which caches artifacts saving both bandwidth and time required to retrieve a software artifact from a remote repository, and
• A host for internal artifacts providing an organization with a deployment target for software artifacts.

In addition to these two core features, a repository manager also allows you to manage binary software artifacts through the software development, quality assurance, and production release lifecycle. In addition to these core features, a repository manager can search software artifacts, audit development and release transactions, and integrate with external security systems such as LDAP. A repository manager is a powerful tool that encourages collaboration and provides visibility into the workflow which surrounds binary software artifacts.

A richer, more detailed description of the features of a repository manager include:

Management of Software Artifacts

A repository manager is able to manage packaged binary software artifacts. In Java development, this would include JARs containing bytecode, source, or javadoc. In other environments, such as Flex, this would include any SWCs or SWFs generated by a Flex build.

Management of Software Metadata

A repository manager should have some knowledge of the metadata which describes artifacts. In a Maven repository this would include project coordinates (groupId, artifactId, version, classifier) and information about a given artifact’s releases.

Proxying of External Repositories

Proxying an external repository yields more stable builds as the artifacts used in a build can be served to clients from the repository manager’s cache even if the external repository becomes unavailable. Proxying also saves bandwidth and time as checking for the presence of an artifact on a local network is often orders of magnitude faster than querying a heavily loaded public repository. Proxying an external repository such as the Central Maven repository is also an act of good citizenship; reducing the bandwidth burden on Central helps to preserve a valuable public resource.

Deployment to Hosted Repositories

Organizations which deploy internal snapshots and releases to hosted repositories have an easier time distributing software artifacts across different teams and departments. When a department or development group deploys artifacts to a hosted repository, other departments and development groups can develop systems in parallel, relying upon dependencies served from both release and snapshot repositories. Finding an efficient way to distribute the binary software artifacts during the development cycle is essential for an organization that needs to scale system complexity and number of developers. Once you start using Nexus as a sharing mechanism across development teams, each team can then focus on smaller, more manageable systems. The web application team can focus on the code that directly supports the web application while it depends on the binary software artifacts from a team managing an Enterprise Service Bus.

Searching an Index of Artifacts

When you collect software artifacts and metadata in a repository manager, you gain the ability to create indexes and allow users and systems to search for artifacts. With a Nexus index, an IDE such as Eclipse has almost instantaneous access to the contents of all proxy repositories (including the Central repository) as well as access to your own internal and 3rd party artifacts. If a user needs to search for a particular artifact, they can use the built-in auto-completion capabilities of Eclipse, and the IDE will perform a query against an index of the repository. If you need to update a library to the latest version, click on the POM editor and use the auto-complete feature in m2eclipse. If you need to search for all artifacts which contain a specific class name, you can use m2eclipse to search an index of Maven repository artifacts by class name. While the Central repository transformed the way that software is distributed, the Nexus index format brings the power of search to massive libraries of software artifacts.

Infrastructure for Artifact Management

A repository manager should also provide the appropriate infrastructure for managing software artifacts and a solid API for extension. In Nexus, Sonatype has provided a plugin API which allows developers to customize both the behavior and functionality of the tool. Here are just some of the features which are available as Nexus Plugins in Nexus Professional: Release Audits and Compliance, Support for Workflow and Process, Integration with External Security Providers.

Enterprise Repository Management

Once you adopt the core features of a repository manager, you start to view a product like Nexus Open Source or Nexus Professional as a tool which enables more efficient collaboration between development groups. Nexus Professional builds upon the foundations of a repository manager and adds capabilities such as Procurement and Staging.

Managing Project Dependencies

Many organizations require some level of oversight over the open source libraries and external artifacts that are let into an organization’s development cycle. An organization could have specific legal or regulatory constraints which require every dependency to be subjected to a rigorous legal or security audit before it is integrated into a development environment. Another organization might have an architecture group which needs to make sure that a large set of developers only have access to a well-defined list of dependencies or specific versions of dependencies. Using the Procurement features of Nexus Professional, managers and architecture groups have the ability to allow and deny specific artifacts from external repositories.

Managing a Software Release

Nexus Professional adds some essential workflow to the process of staging software to a release repository. Using Nexus Professional, developers can deploy to a staging directory which can trigger a message to a Release Manager or to someone responsible for QA. Quality assurance (or a development manager) can then test and certify a release having the option to promote a release to the release repository or to discard a release if it didn’t meet release standards. Nexus Professional’s staging features allow managers to specify which personnel are allowed to certify that a release can be promoted to a release repository giving an organization more control over what software artifacts are released and who can release them.

Integration with LDAP

Nexus Professional integrates with an LDAP directory, allowing an organization to connect Nexus to an existing directory of users and groups. Nexus authenticates users against an LDAP server and provides several mechanisms for mapping existing LDAP groups to Nexus roles.

Advanced Security

Using Nexus Professional, an organization can define a master User Password Encryption Key. Each user will be given a separate Maven settings file with an encrypted password using the Maven Nexus plugin. When users interact with Nexus, Nexus uses the User Password Encryption Key to decrypt a user’s Nexus credentials avoiding the need to send an easily compromised plain-text password over the network.

Settings Templates

Nexus Professional allows you to define Maven settings templates for developers. Developers can then automatically receive updates to Maven settings (~/.m2/settings.xml) using the Maven Nexus plugin. The ability to define Maven settings templates and to distribute customized Maven settings files to developers makes it easy for an organization to change global profiles or repository configuration without relying on developers to manually install a new settings file in a development environment.

p2 Repository Support

Nexus Professional supports the p2 repository format used by the new Eclipse provisioning platform. You can use the p2 plugin to consolidate, provision, and control the plugins that are being used in an Eclipse IDE. Using Nexus procurement, repository groups, and proxy repositories to consolidate multiple plugin repositories, an organization can use Nexus Professional to standardize the configuration of Eclipse IDE development environments.

For more Information about Sonatype Nexus: http://www.sonatype.com/products/nexus

To download your free trial of Nexus Professional: http://www.sonatype.com/products/downloads