The Nexus 1.7.2 release offers an improved search interface making it even easier to locate the libraries and artifacts you need in Nexus.  Sonatype has published a version of Nexus 1.7.2 on http://repository.sonatype.org which contains some dramatic improvements to the search interface.   Download the new Nexus Open Source or Nexus Professional release and start searching for artifacts.

What is new in the Nexus 1.7.2 search interface?

• Search results now link directly to the latest version of a matching artifact.
• Selecting a search result immediately displays information about the matching artifact.  You can browse artifact information from the search interface.
• (Nexus Professional) Archive browsing and artifact metadata are available from the search interface.
• Matching artifacts of different types (pom, jar, war, zip, etc.) can be downloaded from the search results page.

This release takes the effort out of searching for artifacts in Nexus.  Here are some sceenshots of the new interface now available on http://repository.sonatype.org and soon to be available in the 1.7.2 release of Nexus Open Source and Nexus Professional.

If you are searching for artifacts in Nexus, start with either the Advanced Search interface or the Welcome panel shown below.    This Welcome panel is the first thing you will see when you load Nexus in the browser, to see the welcome screen go to http://repository.sonatype.org.

To search for an artifact, just type in a keyword.  A keyword can be a groupId, an artifactId, or just the name of a project.   If you were searching for the latest version of the Guice library, you would type in “guice” in the Welcome panel and either press Return or click on the search icon to the right of the search box.    Searching for Guice will show the following result panel.

What’s new in this interface?

• Look at the Version column in the search results.   In this version of the search interface, we decided to list the most recent version.    If you need to view a different version, click on “Show All Versions”.   Clicking on “Show All Versions” will drill down into the list of available versions.
• Look at the Download column in the search results.   This Download column contains direct download links for the most recent version of the artifact.   To download a matching artifact, just click on a link in this column.
• Select a search result, and you will see the artifact in the Repository Tree in the lower left-hand quadrant of this interface.   This is helpful to give you context for an artifact.   An artifact could be present in more than one repository.  If this is the case, click on the value next to “Viewing Repository” to switch between multiple matching repositories.
• In the lower right-hand quadrant of the interface, you will see a number of tabs which show information about the selected search result:
  • Maven Information: This contains basic identifiers and a snippet of XML you can use to add this artifact as a project dependency.
  • Archive Browser (Nexus Professional): This gives you a way to explore the contents of an archive in the repository.  You can view the files and folders contained in a matching search result.
  • Artifact Information: This tab contains timestamps, file size, checksum values, and a list of repositories containing a given artifact.
  • Artifact Metadata (Nexus Professional): This tab shows all of the built-in and custom metadata associated with an artifact.

This new search interface will be a part of the Nexus 1.7.2 search interface available in both Nexus Open Source and Nexus Professional.

With the 1.7.1 release Nexus Professional now supports multi-level staging and build promotion.   With our existing staging plugin, you can release build artifacts to a temporary staging repository to allow for testing and certification before making a final decision to release artifacts to a hosted repository.   With multi-level staging, you can add additional steps to your release process.   If you need multiple levels of testing or validation, you can now define both staging profiles and “build promotion” profiles.

When you stage an artifact in Nexus Professional, Nexus creates a temporary staging repository and exposes staged artifacts in a repository group.   When you promote a staging repository with a build promotion profile, you can configure Nexus to add promoted artifacts to additional repository groups.

To explore this new feature of Nexus Professional, consider the following workflow illustrated in the previous figure :

• Stage: A developer publishes artifacts to a QA staging profile which exposes the staged artifacts in a QA repository group.
• Promote to Beta: Once the QA team has completed testing, they promote the temporary staging repository to build promotion profile exposing the staged artifacts to a limited set of customers who have agreed to act as a beta testers.
• Release: Once this closed beta testing period is finished, the staged repository is then released.  The artifacts it contains are published to a hosted release repository and exposed via the public repository group.

To support this multi-level staging feature, configure a Build Promotion profiles to expose promoted release artifacts to additional repository groups.  Build promotion profiles are configured alongside Staging profiles in the Staging Profiles panel.When you create a Build Promotion profile, you configure it to expose promoted artifacts via selected repository groups.When you need to promote a Staging Repository to a Build Promotion Profile, you select the Staging Repositories to promote and click on the Promote button.After clicking Promote, you can then select a Build Promotion profile. For more information about Nexus Professional’s support see “Multi-level Staging and Build Promotion”, and “Configuring Build Promotion Profiles” in the Sonatype Nexus book.

Sonatype is happy to announce the availability of Nexus 1.7. We’ve cut a new release for both Nexus Open Source and Nexus Professional. This post walks through the changes introduced to Nexus Open Source. 

New Features in Nexus Open Source

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

• Improved, Drill Down Artifact Search Interface
• Repository Groups can contain both Repositories and other Repository Groups

Improved, Drill Down Artifact Search Inteface

When you search for artifacts in Nexus 1.7 you will be presented with a drill down search interface. We made this change to make it easier to search for artifacts, which might return hundreds of results. Using the drill down search inteface, you can quickly navigate to just the artifacts you are interested in.

NOTE:

We have changed the local format of the lucene indexes, it is required that users reindex all repositories in their Nexus server to start benefitting from the changes (and for search to work properly).

Groups of Groups

Repository Groups can now contain other Repository Groups. This change has already come in handy for developers who want to create variations of the standard public repository group. If you have a series of repository groups which are all similar, you can capture these similarities in another group.

Sonatype is continually making efforts to improve Nexus and make investments in the open source community.  Stay tuned for new features in Nexus Professional.

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.

Over the weekend, the JBoss repository team put the final pieces in place to complete the switch to Nexus Pro. We’ve been working with them since early this year to perform analysis and tool support for the conversion. Their team performed very diligent testing of the entire system prior to the conversion. Kudos to Paul for such an orderly and thorough process. The timing of the production switch is great because we are nearly done helping to clean up the Java.net repositories.

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.

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.

We recently started raising the minimum criteria for artifacts coming into Central:

• Blind rsync transfers of random repositories are no longer being added and will be phased out over time
• All artifacts must be properly signed with GPG signatures that are publicly verifiable
• sources and javadocs must be included
• scm urls must be included
• No external repository definitions

That last one seems to cause the most commotion for users that depend on artifacts not currently in Central and I wanted to take this opportunity to show why this is being done.

The urls you see below are listed as RELEASE repositories found in the poms of a prominent repo we’re attempting to clean for syncing to Central. In the list below you will find some interesting bits:

• file based urls
• urls with private ip subnets
• snapshot repositories (remember this is a list of the RELEASE repos only according to the poms
• Links to websites (like [http://maven.apache.org]) or wikis
• Many sites that no longer exist
• Repositories that are actually mirrors of Central (Ibiblio)
• Repositories who’s contents are already in Central (codehaus)

Of the few repositories that actually do still work, many of them have what I would  call “garbage” in them. I’ll define garbage here as things that didn’t originate from this project and are either hacked/patched versions and/or duplicates of artifacts that are found somewhere else.

When you start blindly using these repos, best case you could get artifacts who’s provenance is suspect and your builds are slowed down because Maven is sent off on a wild goose chase. Worst case, you still have to find these repos by hand and override the bad urls.

In the list below, I think my favorite is the dynamic search of a Fisheye repository at Atlassian.com. I’m sure they love having thousands of builds doing automated searches of their Fisheye service looking for every artifact in a build.

• file://${basedir}/src/repository
• file:${brillien_basedir}/../lib
• file:${project.basedir}/lib
• file:${project.basedir}/lib/
• http://10.5.5.82:8081/artifactory/plugins-releases
• http://10.5.5.82:8081/artifactory/plugins-snapshots
• http://archiva.openqa.org/repository/releases/
• http://artifact-repo.int.gestalt-llc.com:8080/archiva/repository/nct-core-releases
• http://artifact-repo.int.gestalt-llc.com:8080/archiva/repository/nct-core-snapshots
• http://artifact-repo.int.gestalt-llc.com:8080/archiva/repository/repo
• http://bits.netbeans.org/maven2
• http://cvs.apache.org/maven-snapshot-repository
• http://developer.jasig.org/repo/content/groups/m2-legacy/
• http://dist.codehaus.org/mule/dependencies/maven2
• http://download.csssprites.org/maven2/
• http://download.java.net/javaee5/external/shared
• http://download.oracle.com/maven
• http://easymock.org/maven/repository
• http://egit.googlecode.com/svn/maven/snapshot-repository
• http://fest.googlecode.com/svn/trunk/fest/m2/repository
• http://fforw.de/m2repo/releases/
• http://fisheye4.atlassian.com/browse/~raw,r=trunk/hudson/trunk/hudson/plugins/git/maven-repository
• http://groovydice.sourceforge.net/m2repo
• http://guiceyfruit.googlecode.com/svn/repo/releases
• http://java.freehep.org/maven2
• http://jets3t.s3.amazonaws.com/maven2
• http://jflex.sourceforge.net/repo/
• http://maven1.glassfishwiki.org/
• http://maven.apache.org
• http://maven.dyndns.org/2
• http://maven.dyndns.org/glassfish/
• http://maven.glassfish.org/content/groups/glassfish
• http://maven.glassfish.org/content/groups/public/
• http://maven.ocean.net.au/external
• http://maven.ocean.net.au/release
• http://maven.ocean.net.au/snapshot
• http://maven.restlet.org
• http://maven.sfbay/mirrors/java.net
• http://mirrors.ibiblio.org/pub/mirrors/maven2
• http://ndeloof.free.fr/maven2
• http://nexus.openqa.org/content/repositories/releases
• http://oss.repository.sonatype.org/content/groups/cometd
• http://people.apache.org/maven-snapshot-repository
• http://people.apache.org/~mrdon/repository/
• http://people.apache.org/repo/m2-incubating-repository
• http://people.apache.org/repo/m2-snapshot-repository
• http://people.apache.org/repo/m2-snapshot-repository/
• http://repo1.maven.org/maven2
• http://repo1.maven.org/maven2/
• http://repo2.maven.org/maven2
• http://repo2.maven.org/maven/2
• http://repo.aduna-software.org/maven2/releases
• http://repo.ddsteps.org/maven/release/
• http://repo.nhncorp.com/maven2
• http://repo.opennms.org/maven2
• http://repository.codehaus.org
• http://repository.ops4j.org/maven2
• http://repository.ops4j.org/maven2/
• http://scala-tools.org/repo-snapshots/
• https://games-darkstar.dev.java.net/nonav/snapshots
• https://hudson.dev.java.net/source/browse/*checkout*/hudson/hudson/main/lib
• https://m2proxy.atlassian.com/repository/public
• https://maven2-repository.dev.java.net/nonav/repository
• https://maven2-repository.dev.java.net/nonav/repository/
• https://maven.atlassian.com/content/groups/public/
• https://maven-repository.dev.java.net/nonav/repository
• https://maven-repository.dev.java.net/nonav/repository/
• https://maven-repository.dev.java.net/repository
• https://maven-repository.dev.java.net/repository/
• http://snapshots.jboss.org/maven2
• http://snapshots.repository.codehaus.org/
• http://source.db4o.com/maven
• http://sshd.googlecode.com/svn/m2-repo
• http://svn.apache.org/repos/asf/servicemix/m2-repo
• http://svn.magnolia.info/maven/m2
• http://svn.sonatype.org/flexmojos/repository/
• http://tek42.com/maven2
• http://wicketstuff.org/maven/repository
• http://www.agilejava.com/maven/
• http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/rt/eclipselink/maven.repo
• http://www.eviware.com/repository/maven2/
• http://www.ibiblio.org/maven
• http://www.ibiblio.org/maven2
• http://www.ibiblio.org/maven2/
• http://yusuke.homeip.net/maven2

When we sync these poms to Central, it is highly likely we will simply ditch all of these references. We don’t take changing poms likely, but in this case it is clearly the lesser of two evils. Having the ability to leverage artifacts in some other repo is a nice fix in the moment, but once you release your project this way, you forever become a slave to that project maintaining the repo.

In order to improve the experience for everyone, we are working to block this from happening in Central. We have several efforts underway to help minimize this impact, and that primarily includes making it easier to get your artifacts and third party artifacts into Central. Stay tuned for more exciting announcements on this topic.

This is the first production release of m2eclipse in more than a year, and it couldn’t come any sooner.  In this release, you’ll find that we’ve separated the update sites. There is now a core update site and an extras update site which contains optional components.  For more details about the installation, please read the installation instructions on the m2eclipse site.

One important note about the 0.10.0 release: you cannot upgrade from 0.9.8 or 0.9.9-dev. You must either uninstall the previous version from your Eclipse installation, or you should start with a new installation of Eclipse. The recommended version of Eclipse for this release is 3.5.1. You can download this eclipse distribution from http://www.eclipse.org/downloads.    The rest of this post details what is new and noteworthy about the m2eclipse 0.10.0 release.

What’s New and Noteworthy in this release?

• Stability – We’ve spent the last year working on stability and performance. If you are used to using m2eclipse 0.9.8, you’ll notice a remarkable performance improvement between these two versions.

• Integrated with Maven 3.0 – This release of m2eclipse includes Maven 3.0-alpha-6+. One of the primary drivers of the Maven 3.0 effort was to reimplement some of the “guts” of Maven to make it easier to embed within frameworks like the Eclipse IDE. If you are wondering what changes need to be made to your projects to use Maven 3.0, the answer is “none”. Maven 3.0 is a revolutionary upgrade that will enable the next generation of development tools, but you don’t have change a thing in your project. It should all just work.
  • Compatibility with Maven 3.0 CLI behaviour
  • Major performance improvements compared to 0.9.8
  • Full support for proxy/mirror/auth configuration as per settings.xml
  • Note for Maven 2 Users: If you need to configure m2eclipse to use a Maven 2 installation, you can do so in the m2eclipse preferences.

• Maven Project Lifecycle Mapping framework – This framework gives you the ability to customize the Maven plugins and plugin goals which are involved in your development cycle. If you need to configure the Maven Resources plugin to update resources every time your project is built within Eclipse, there is a new tab available in the m2eclipse POM Editor.
  • Developed using the new Project Configurator API
  • Eclipse project configuration and build can be fully customized for project types and individual projects
  • Implementation of plexus-build-api to allow mojos participate in eclipse incremental/full builds
  • Support for modello, plexus metadata, antlr3, build-helper, resources (from site-extras)

• Reimplemented nexus-indexer integration and repositories view – m2eclipse is very tightly integrated with the Nexus indexer, and it uses it to quickly locate dependencies and artifacts. This release adds a new Repositories View which gives you the ability to inspect, modify, and manage the Maven repositories (including your Local Maven Repository) in an easy-to-use interface.
  • m2eclipse now tracks repositories defined in settings.xml and project pom.xml files
  • New option for disabled, min, or full index details for each Repository
  • Supports the new Incremental Index Standard
  • Remote index files are cached in maven local repository and shared between workspaces, as a result workspace initialization in m2eclipse is much faster.

• Preliminary eclipse 3.6 support – While we don’t yet recommend the use of Eclipse 3.6, this release does start to add preliminary support for the platform.

When we first set out to design the external security realm (LDAP/ Crowd, etc) support in Nexus Core, we had one primary concern and that was to make it easy to integrate with systems having huge numbers of users.   Nexus was designed as a tool to be used to support the largest open source communities with thousands of developers and hundreds of projects, and like most large enterprises, these communities have settled on solutions like LDAP, Active Directory, and Crowd as a way to manage user credentials and permissions.  A secondary concern was to support any level of integration with these external security realms, specifically:

• delegating only authentication to an external server
• delegating both authentication and authorization to an external server
• delegating everything but authentication promotion permissions to an external server

These interactions were gleaned from years of experience working with customers at all levels. Some have completely centralized control over passwords and roles. Others have a situation where there’s a global repository but the roles don’t match reality, or are too hard to get updated.    We wanted to create a system that would both integrate with centralized authentication servers and allow for a sensible way to override role assignments directly in Nexus.

All of this is Core functionality works the same with all types of security realms.   We offer LDAP and Crowd support and the rest of this post will discuss the generic security model that works with every security realm that is available.  It is possible to define multiple external realms for Authentication and/or Authorization in the Server settings. This ordered list is used to validate credentials and select roles.  When a user attempts to authenticate in Nexus, it will iterate over the list until it can successfully authenticate a user.

Order Realms

For performance reasons it is almost always beneficial to move any external realms to the bottom of the list. Nexus will not check other realms once it finds a user. The first two realms are fast because the model is held in memory. The external realms tend to be slower, as they need to connect to a remote system.

Navigate to the ‘Server’ pane, scroll down to ‘Security Settings’ section, and move your external realms to the bottom of the list. (do not forget to save!)

Now that we’ve defined the ordering, lets take the full integration approach.

Authentication and Authorization

Lots of organizations have some central user management service which has the users identity, credentials, and which groups they belong to.  Nexus is able to delegate login and authentication to that server.  For authorization we map Nexus roles to your organization’s roles/groups.   If all your users are in a group named ‘users’, you can map this group to a Nexus role of the same name and assign it the desired permissions.   Once a user authenticates against an external realm, their groups will match up against Nexus roles that define the specific permissions to grant.

To map a role, navigate to the ‘Roles’ pane and select the ‘Add External Role Mapping’:

A dialog will pop up, you will need to select the security realm you are using and the group you want to be mapped.  This group is a group that is managed by the external server.   In this case, we’re mapping the “users” group in LDAP to a role in Nexus.

You then need to select which Nexus roles you want to map to your organization’s group.   Here you see the new role mapping.   To add Nexus permissions for this group, just drag Nexus roles and privileges from the Available Roles / Privileges list to the Selected Roles / Privileges list.

By mapping the external roles/groups to Nexus Roles, we are able to grant permissions to “unnamed” users. That is, ANY user that successfully authenticates against the external realm, having the group “users” will inherit the permissions granted to the Nexus “users” role. You do not need to tell Nexus about all these users ahead of time simply to assign them roles. Imagine trying to do that for 6000 users. Nexus is unique among Repository Managers with this approach.

Authentication only

Some organizations have central user management but do not maintain user groups, or the groups are unrelated to development. For this use case, Nexus can be configured to delegate the login to the server, but all the user roles are configured inside of Nexus. This provides the benefit of allowing users to use their company wide accounts while letting a Nexus administrator manage roles.

Go to the ‘Users’ pane, select a user and give them a role. In the image below, I added ‘Nexus Developer Role’ to the user ‘Maven’.

Unlike the first example, you need to manually go to each user that needs access and grant them the appropriate Nexus roles.   In this model, the Nexus administrators take on more responsibility for granting the appropriate users the appropriate level of access to the repositories they need to use.

Authentication Promotion

The last option is a combination of the two previous. The User login and list of roles are delegated to a central server, but additional roles are assigned to individual users in the Nexus UI.   In this model, Nexus administrators only need to augment roles for the few users that need to special permissions in Nexus.   For example, user Joe Coder is a developer and is part of the organization’s basic ‘development’ group. If Joe needs helps administer Nexus, all you need to do is assign him the ‘Nexus Administrator Role’.

To assign a user a specific role or privilege, click on User in the Security menu and select the user you want to add a role or privilege to.  You should see the same interface that was shown in the previous section.   While the user will have a set of basic roles mapped from the external security realm, you can add special privileges that allow a user to promote a staged release or administer the Nexus interface.

In this example it is easy to see the power of Nexus’s security framework. In a few clicks you can give your whole organization access to a Nexus instance. With a few more clicks you can promote a user to and admin, or just give them access to an additional artifacts.

Summary

The Nexus Core security support for External realms was designed specifically to manage several different integration scenarios from full external realm delegation to mixing and matching authentication and authorization so that it could work for any type of realm and organization. Wherever possible we made sure to imagine “will this work with 6000 users?”, and this is why the role to group mapping is supported and also why we don’t attempt to list all external users anywhere by default. At the lowest levels we also took care to empower realm authors to integrate in many different ways beyond just roles and permissions. A realm gets access to the exact url and http method (get/put/post/head/delete) and thus can evaluate each request using its own set of rules if desired. This is all part of our strategy to provide the most flexible and robust Repository Manager you can find.

This post focused more on the theory and mechanics of managing external realms in Nexus. If  you would like to see a more end to end solution involving securing subsets of repositories, you can see Managing OSS Forges with Nexus as most of the topics covered there directly apply to organizations of all sizes.

In addition to managing and maintaining the Maven Central repository, I also serve as the administrator for two very large forge repositories: repository.apache.org and nexus.codehaus.org. This post is going to dive into the details of the best practices that I’ve developed to maintain these very large instances. I will focus on the configuration of Nexus in this post, but if you’re interested in system level details, those are documented here.

Both of these repositories have a few things in common that have driven the design:

• there are many disparate projects deploying artifacts that require fine grained access control per project
• release repositories are synced to central
• they are the most commonly used snapshot repositories in the maven ecosystem
• the majority of users are anonymously reading the snapshots
• they are transitional repositories that replace older static repositories

They also have a few things that are very different:

• Apache is a Solaris Zone
• Codehaus is an Ubuntu Jeos VM
• Apache is using httpd for reverse-proxying and ssl
• Codehaus is using Nginx for reverse-proxying and ssl

This post contains two sections, the first covers some system-wide Nexus configuration, the second contains details about adding individual projects, along with security and staging configuration. If you are setting up a public Maven repository, this post might give you some ideas about configuration and administration issues that you’ll need to think about.

Nexus System Configuration

We want to protect all authenticated traffic, so both systems rewrite all http access to https (you can see how that’s done in the server setup linked above). However, since 99% of all traffic to these systems is anonymous, I’ve allowed the snapshot urls to poke through without being redirected.

Since I am using reverse proxies in front of Nexus, and the protocol doesn’t have a good way to tell Nexus what the inbound protocol was, I need to tell Nexus how to generate absolute urls that are used in the REST API. This is done by setting the following options in the server configuration pane:

The systems are configured with just two hosted repositories: releases and snapshots. Both systems are transitional, meaning that projects elect to convert at a convenient time. To support this, I proxy the old snapshot repository and aggregate it with the locally hosted snapshot repo. When you hit http://repository.apache.org/snapshots or http://nexus.codehaus.org/snapshots, you’re hitting this group and it appears as one repository. We also have a staging group that is used to aggregate all staging repos that haven’t yet been promoted. Here’s what the repository list looks like:

One benefit to using Nexus in these forge setups, is that we are able to configure rules that automatically check staged artifacts before they can be promoted. This includes things like validating the pgp signature is present and signed with a publicly accessible key, looking for sources and javadocs, validating the pom, etc. This is one way we are helping to improve the data in Central, by helping to correct it right at the source. Since these rules are tied in to the Staging support, we want to disable the ability to deploy directly to the releases repository. This is done by setting the repository url to be read-only:

I also have configured the following jobs:

• Configuration Backup – Backs up the Nexus Configuration files. I have it set to run daily and to keep 10 days of backups
• Publish Indexes – This packages the internal real-time indexes into a format that is consumable by downstream Nexus’ and M2eclipse users (other tools consume this data as well). I have this set to run daily.
• Purge Proxy Artifacts – Since we’re transitional and proxying the old, static snapshot repositories, I have configured a task to evict items that haven’t been requested in more than 10 days. This just reduces the disk consumption on the repo. If a file is re-requested later, it will be retrieved again from the proxy on demand.
• Snapshot Cleanup – We want to enforce best practices and keep snapshots moving forward. The cleanup task is set to keep a maximum of 3 timestamped snapshots for each artifact for a minimum of 10 days. All snapshots for an artifact are also purged when a release is promoted.
• Empty the trash – All delete operations in Nexus never actually delete, they just move files to a trash folder. This is a security net in case you misconfigure a cleanup task, or simply make a mistake in the ui (like dropping a repo you meant to promote). We keep on top of the trash by scheduling it to run once a week. New in 1.4 is the ability to purge things from the trash only after they have been deleted for x days. I’ve set this to hold things in the trash at least 7 days. This gives projects more than enough time to detect any issues and recover the artifacts.

Project Specific Configuration

Each project needs to have access to only their own artifacts. Nexus supports two different ways to handle the security separation. If you want to read more about the two modes read my previous post:“Optimal Nexus Repository Configuration” .  We have chosen to manage the forge by partitioning a single pair of repositories. The next few steps show how this is done.

First, we define a new Repository Target for this project’s artifacts. Don’t worry if you’re not a regexp genius, wildcards are very easy, and we let you define multiple regexps so you don’t have to figure out more complicated and/or expressions. In the image below, I’ve created a new target called “org.codehaus.org” that will contain all artifacts in the paths /org/codehaus/mojo and below.

Now that we’ve defined our “bucket” of artifacts, we need to create some permissions that are associated with it. You’re probably thinking “create permissions?” Yes, see the Repository Target is a generic concept that lets you arbitrarily group artifacts, but notice we haven’t yet associated the target with any repositories.

NOTE: The logic behind this approach is that you may want to grant people read access to all org.foo artifacts, but what if you only want them to see artifacts that have been promoted and not things that are still being staged?

In this case, we want to grant CRUD (Create / Read / Update / Deleate) to SNAPSHOT artifacts, but only CRU to releases. (Admins only are allowed to delete releases, this prevents problems once things are synced to Central). I will do this in two steps as shown below. First create a set of permissions that link the org.codehaus.mojo Repository Target to “All Repositories”:

Then create a set or permissions that only apply to the hosted Snapshot repository:

Both the Apache and Codehaus forges use the Staging support in conjunction with Staging rules to validate the integrity of releases.

NOTE: Nexus staging is unique in that it’s entirely controlled from the server side, which means Admins can adjust as needed without changing the poms. It’s also designed so that all projects use a single url for deployment that is abstracted from the repository, which provides two benefits: 1) you can change the repository hosting artifacts without changing poms and 2) you can specify the distributionManagement url in just one place, reducing the errors. For example, at Apache we have a parent pom that contains all the logic a project needs to be staged.

We control this in Nexus by creating a Staging Profile. Fortunately the profile reuses the Repository Target we defined earlier:

Not shown are the settings that let you set the validation rules and who should be notified at each promotion step.  Now that we have defined the staging profile, the system automatically created a few new permissions that let you specify who is allowed to stage, drop and promote these artifacts. We want to grant this permissions to users and this is done via roles.

The Codehaus repository is linked to their LDAP system. Nexus takes a unique approach that lets you easily grant access to dozens of users without having to configure each user in the system. We do this by allowing you to “map an external role” and then grant Nexus specific permissions to any user that has this role.  To do this, navigate to the Role pane and select the Add External Role Mapping as shown below:

This brings up a dialog where you can select the external realm (you could have multiple realms), and then you will see a list of all the roles known to the external system. Here I’m selecting “mojo-developers”.

This creates a new role in Nexus with an id matching the external system id “mojo-developers”. Any user authenticated that has this role in the external user account will automatically be granted these permissions.

I now select the roles and permissions I want to grant. Specifically, I grant the following:

• Staging: Deployer (org.codehaus.mojo) - This is a role that was created when I setup the profile. It contains the basic set of permissions needed to allow a user to view, stage, close and drop org.codehaus.mojo staging repositories (only)
• UI: Staging Repositories – This lets the user actually see the staging view, without this they couldn’t see what they staged.
• org.codehaus.mojo – All – Here I’m granting Create, Read and Update for all matching artifacts (remember these are the permissions we created above that apply to all repositories)
• org.codehaus.mojo – snapshots: Here I’m granting delete, but only for the org/codehaus/mojo artifacts in the Snapshot repository.
• Staging: Profile org.codehaus.mojo – (promote): The Staging: Deployer xxx roles give the ability to stage, but not the ability to promote. This permission may be granted to managers, qa, or PMC etc as appropriate. Here we’re letting developers stage and promote their own artifacts.

And we’re done. Notice that I didn’t need to go grant permissions to every user, and I didn’t have to put the users into groups. This is the power that Nexus provides in user management. This is core functionality that applies to any realm you may have, not just Nexus Professional ones.

Now, to illustrate some more power of this approach, what if org.codehaus.mojo later starts managing artifacts under org.mojo? I don’t have to redo everything here, I just extend the Repository Target “bucket” by adding “./org/mojo/.” and instantly all the permissions, staging profiles, etc apply to the new groupId. This has definitely saved me many times at Apache with the Webservices Projects… they have more groupIds than I can count, but they all map back to the same external role. Each time a new one comes along, I just add it to the target and I’m done.

Automating Nexus Administration via REST

This is the process we’ve ironed out over several months. I definitely don’t go through this UI clicking every time. Since Nexus has a full REST API (the UI is just a REST client built in JavaScript), we have developed a set of command line tools that take a few simple inputs like groupId, external role id and project name and automates all of this configuration via REST calls automatically. You can see those tools here and they make a great example of how to integrate Nexus into the DNA of your organization.