If you are a software developer, you most likely rely on a Maven Repository Manager to acquire, manage, and report on open source software artifacts — the building blocks of application development.  Nexus is the industry-leading Repository Manager, and the recent release of Nexus 1.6 brings many exciting upgrades to both Nexus and Nexus Professional.  But how do you decide what version of Nexus is best for you?

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

In Nexus 1.6, we reintroduced a useful little feature that had been available in early 1.0 betas: The ability to have Nexus auto block proxies that are unreachable. What’s improved in this version is the ability to control this feature and the fact that it will auto unblock the repo once it becomes reachable again.

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.

Sonatype is happy to announce the availability of Nexus 1.6. We’ve cut a new release for both Nexus Open Source and Nexus Professional. This post walks through the changes introduced to both Nexus Open Source and Nexus Professional.  Nexus Open Source now supports auto block/unblock for remote repositories which may become unavailable, and Nexus Professional adds some new configuration fields for the Staging Suite.  In addition to these new features, Nexus has now completed the transition to Guice, and we are providing 100% documentation coverage of the Nexus REST API.

New Features in Nexus Open Source

With this release, Nexus Open Source gains the following features:

• Auto Block/Unblock of Unreachable Remote Repositories
• Changes to the Default Group Configuration
• A User Interface for Filing Issues and Problem Reports

Auto Block/Unblock of Unreachable Remote Repositories

What happens when Nexus is unable to reach a remote repository? If you’ve defined a proxy repository, and the remote repository is unavailable Nexus will now automatically block the remote repository. Once a repository has been auto-blocked, Nexus will then periodically retest the remote repository and unblock the repository once it becomes available. You can control this behavior by changing the Auto-blocking Active setting under the Remote Repository Access section of the proxy repository configuration as shown in the following figure:

Changed Default Groups Configuration

We’ve removed “public snapshots” group from the default configuration that ships with Nexus. In Nexus 1.6, the only default repository group is the “Public” group. While the initial versions of Nexus had a separate group for snapshots, it is a better strategy to point all of your developer workstations at a single repository group.

Generating a Nexus Problem Report

We wanted to make it very easy for users to file issues in our JIRA instance. If you encounter a bug or an error in JIRA, or if you have a suggestion, you can now file a report directly from your Nexus instance.   In Nexus 1.6, you can click on “File Issue” in the Nexus menu, supply your Sonatype JIRA credentials, and file a problem report.

Updates to Nexus Professional 1.6.0

A total of 59 issues were filed against Nexus Pro 1.6.0. Among the major improvements in Nexus Pro:

• Conversion from Plexus to Guice
• A Staging Profile can now define a target promotion repository
• The POM Validating Rule in the Staging Ruleset now validates a project’s Parent POM
• POM Validation now tests for the presence of plugin Repositories and repositories.

Nexus Staging Profile Configuration Parameters

In Nexus 1.5, there was no way to associate a Staging Profile with a specific target promotion repository, the user performing a promotion had to select a target hosted repository when they were promoting a staging repository.   In Nexus 1.6, you can define an optional “Promotion Repository” when you define a Staging Profile.   If the Promotion Repository isn’t set, the promotion will still ask the user to choose a promotion repository upon promotion.   If the Promotion Repository is set, all artifacts promoted from this Staging Profile will be promoted to a specified promotion repository.

Improved POM Validation Rules

The POM Validation Ruleset has been modified to validate information in a project’s parent POM.

Complete Nexus REST Documentation

With Nexus 1.6, we have also fully documented the Nexus REST API with Enunciate.   REST documentation is not yet bundled with Nexus, look for a future release to bundle all of this reference installation and serve it directly from your Nexus instance.   For now, you read full documentation of the Nexus REST API from the Sonatype web site.

Nexus is Now Powered by Google’s Guice

In addition to these important features, Nexus has now completely migrated from Plexus to Guice, a lightweight dependency injection framework developed by Google.  If you are a Nexus user, you won’t notice any differences between the Plexus-based Nexus 1.5 and the Guice-based Nexus 1.6.    As we’ve discussed in previous blog entries switching to Guice is part of a long-term strategy, moving to Guice will allow us to devote more of our resources to Nexus features development and less resources to maintaining Plexus.

Downloading and Installing Nexus 1.6

If you are new to repository management, Nexus is, by far, the easiest repository to install. All you need to do is download a distribution, unpack the Nexus archive, and run a simple script. Watch a demonstration of the installation process on Linux and on Windows.

• Download Nexus Open Source 1.6
• Download Nexus Professional 1.6

Upgrading to Nexus 1.6

We’ve changed the location of configuration files for the Java Service Wrapper startup scripts. You can see these differences if you list the contents of ${NEXUS_HOME}/bin/jsw. On a Nexus 1.5 installation you would see this:

/usr/local/nexus-professional-webapp-1.5.0 $ ls ./bin/jsw/
jsw-license/         linux-x86-64/        solaris-sparc-64/
linux-ppc-64/        macosx-universal-32/ solaris-x86-32/
linux-x86-32/        solaris-sparc-32/    windows-x86-32/

Now, on a Nexus 1.6 installation, the same directory contains different configuration folders and platform options:

/usr/localnexus-professional-webapp-1.6.0 $ ls ./bin/jsw/
conf/                linux-x86-32/        solaris-sparc-32/
lib/                 linux-x86-64/        solaris-sparc-64/
license/             macosx-universal-32/ solaris-x86-32/
linux-ppc-64/        macosx-universal-64/ windows-x86-32/

If you are upgrading from a Nexus 1.5 instance to a Nexus 1.6 instance you will need to make sure that you are using the latest “nexus” script in the appropriate platform folder. If you previously installed Nexus on a Linux system and copied the ./bin/jsw/(platform)/nexus startup script to the /etc/init.d directory you will need to make sure that you copy the newer version of this nexus script (or create a symbolic link to the newer version of the script).

If you’ve made customizations to your startup script, the important configuration parameter to update is WRAPPER_CONF. In a Nexus 1.5 installation, the WRAPPER_CONF has the following value:

WRAPPER_CONF="../../../conf/wrapper.conf"

This should be changed to the following value in Nexus 1.6:

WRAPPER_CONF="../conf/wrapper.conf"

If you have customized the wrapper.conf, merge your changes into the new one instead of copying it, we’ve made several updates to the paths and set some default timeouts that you should pick up.     We can’t emphasize this point enough, do not just copy your own customized version of wrapper.conf atop the newer version.

In addition to this simple configuration change, you should also take note of the additional platform now available in the ./bin/jsw directory: macosx-universal-64. If you are running Nexus on a 64-bit OSX platform, you should start using this startup script instead of macosx-universal-32.