You’ll want to make sure that you run your repository manager on a server that is up to the task. The last thing you need is for Nexus to run out of space during a critical release because it is running on inadequate hardware. Disk space is cheap, broken builds are not.

In this post, I focus on storage requirements for Nexus. I discuss general recommendations and point you at resources we’ve developed to help you come up with accurate estimates for how much disk space you’ll need.

Disk Space

Disk space is going to be the critical parameter for a Nexus installation. At its core, Nexus is simply a collection of files and a set of services to index and serve these files. If you integrate Nexus into your development process and come to depend on it as a collaboration mechanism, you can easily consume hundreds of gigabytes (or even terabytes) of space.

Coming up with a simple guideline for storage requirements is difficult as it depends on a number of factors: How many projects do you have? How large are the artifacts being deployed to Nexus? How frequently are these artifacts deployed? and How long do you keep your releases? How much open source are you consuming from Central? How often do you update external dependencies? and How many 3rd party artifacts do you need to upload?

If you deploy artifacts to Nexus, your internal, hosted repositories are what will end up consuming the most space over time. At a large organization with hundreds of projects and frequent releases, it is very easy to create systems that consume a surprising amount of space. If you are interested in diving into the details and coming up with an estimate for your organization, watch “Getting Scientific about Sizing Nexus”.

An Initial Starting Point

While some of our engineers like to aim high with an initial recommendation of 250-500 GB, I like to aim a little lower. Sure, if you are rolling Nexus out to a 5,000 developer installation with thousands of projects, you may very well want to start with 1 TB. On the other hand, if you are gradually rolling Nexus out to a department or two, you should start with a more reasonable number: 50 or 100 GB.

I recommend starting with 50 or 100 GB, and I also recommend being prepared to expand that number as needed. Starting with this smaller number avoids the problem of procuring a huge chunk of disk space only to watch it sit idle for the months (or years) it will take you to consume all this space. Aim low, plan to expand.

Conclusion

Your initial estimate for disk space consumption is going to be just that, an estimate. Having set up scores of Nexus instances for organizations of all sizes, my experience has been that you’ll want to do some ballpark estimates and then multiply that estimate by a factor of two or three. When you connect systems like Hudson to Nexus and deploy snapshots from every integration build, you’ll appreciate the extra space.

As you start to use Nexus, you’ll have to tweak your scheduled jobs to make sure that you are periodically removing old snapshots and regularly keeping an eye on storage. If you expand the number of projects or developers using a Nexus instance, you’ll want to revisit some of these initial estimates and make sure that your system has enough storage to keep track of all the artifacts it is caching and storing.

We’ve enhanced the leading repository manager to help you develop better software faster.  Nexus 1.9.2, recently released, adds a number of new features.

Stop Running Tasks

You can stop running processes immediately and no longer have to wait for them to complete.  This is quite useful for recovering from high load situations.  Stopping a running process is easy — just select the process and click on the cancel button (see Figure 1). You can also delete tasks without waiting for them to finish. Delete will automatically stop the process and then delete it.

Improved Maven 2 Support

You’ll get improved support for environments with both Maven 2 and Maven 3 clients. Nexus now suppresses Maven 3 metadata automatically when communicating with Maven 2 clients. This improvement allows you to use such mixed environments successfully.

Enhanced User Information

Sonatype Pro for Nexus customers can better audit who uses each Nexus server with usage information that includes userid and user agent.

Download Nexus Today

So what are you waiting for, download the latest version of Nexus OSS  or the professional version from our support site.  Learn more about Sonatype Pro for Nexus.

Figure 1. Stop running processes easily with the new cancel button

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.

The following demonstration video was shown in the Sonatype booth at last month’s Jfokus 2010 in Stockholm, Sweden. This video provides a quick walkthrough of the major features in Nexus Scheduled Jobs.

Highlights of this demonstration:

The following demonstration video was displayed in the Sonatype booth at last month’s Jfokus 2010 in Stockholm, Sweden. This video provides a quick walk through of the System Feed and Log file UI available in Nexus.

Hightlights of this video:

The following, audio-less demonstration video was used at our booth at Jfokus 2010 in Stockholm, Sweden. It is a brief walkthrough of some of the major features of Nexus Proxy repositories. If you are evaluation Nexus, this is a chance to see Nexus UI in action.

Highlights of this demonstration reel:

This demonstration video was used at our booth at last month’s Jfokus 2010 in Stockholm, Sweden. It provides a quick, audio-less overview of some of the major features of Nexus Hosted repositories:

Highlights of this demonstration reel:

Nexus OSS Core has more than 120 REST Resources published. And that number is just increasing with new Nexus Plugins. Not to mention Nexus Pro that comes with even more plugins and more REST resources.    Everything you do in Nexus, whether you use the Maven Nexus plugin or the Nexus UI, is interacting with a REST service that is available to you if you want to write your own customizations and scripts.   It has been this way since we started the project in 2007.  In this post, I’m going to discuss how this came to be, how Nexus was developed with REST in mind from the beginning.

Nexus: A Core of REST Services

When we started the Nexus project, I called it a “blind” application.  A “blind” webapp is one with no UI technology whatsoever built-in.   All it publishes is a few static files, and a REST API.   All of the UI that you see in Nexus is Javascript.   Your browser executes Javascript which, in turn, interacts with a set of services.   The only presentation technology on the server side is a trivial Velocity template used to render the initial “shell” of the page.

The server-side application you call Nexus, doesn’t generate the UI, that is all Javascript.   It is a completely separate and standalone application, that runs in your browser! A self contained JavaScript application (powered by ExtJS), that communicates with Nexus server, using REST calls only.  This has one very important consequence: whatever Nexus functionality you are able to reach using the Nexus User Interface (and I do mean all), you can do with a plain REST client.     If you want to automate a task, you can use a tool like curl, or some Ruby script, or any HTTP capable client.   You can even start to implement your own custom interface if you would like a completely customized UI.

As I said, it was like this since day one. But, we always had one major issue that prevented wider acceptance of Nexus’ REST API: we had no up-to-date documentation for it.    It wasn’t a priority, we spent much of our time trying to integrate the only existing REST framework (restlet.org) with Plexus, and since we were moving so quickly to implement new features, we didn’t think it made sense to stop and document an ever-changing interface.  We did maintain a wiki page which described the REST services from the beginning of the project, it always provided stale information given our aggressive development pace.

REST Documentation: Using Enunciate

I’ve been looking at the Enunciate project for some time, and it appears to be the solution to our REST document issues.  Enunciate is a cool project hosted on Codehaus, with a bold promise:

Enunciate is designed to make your life easier. Enunciate deals with your deployment difficulties, documentation, and client-side code. By using Enunciate to publish your service interfaces, not only will you have all three Web service interfaces (SOAP, REST, and AMF), but you’ll also have full up-to-date documentation generated, strongly typed ActionScript code that you can use to invoke your remote services from your Flex code, and rich client-side libraries that can be used to access your Web services from a variety of platforms (including Mac/iPhone).

Our initial plans are to use Enunciate in a “lite” mode to generate documentation (and potentially client side code) for our current REST API. Later, we plan to integrate it more closely into new Nexus “Remoting API” implementation, and it will be the backbone of our REST services when we will implement version 2.0 of our API.

Here is just a taste of what is to come.  We’ve used Enunciate to generate documentation for our REST services, and the work is proceeding very quickly.   Here is a snapshot of the documentation we will be releasing soon.

Remaining Problems to Solve

When our REST API was concieved in Q4 of 2007 we didn’t have the rich array of options that we have today.   One major REST library was available, and that was Restlet.  JSR311 wasn’t around back then, so we were forced to code directly to the Restlet API.  Back in 2007, it was very cool to create Plexus components that were then automatically published as REST Resources in Nexus. But today, the same thing looks very cumbersome and is not what one would call a “state of the art”. Back then, we had these goals in mind:

• have complete REST API published on Nexus
• have a decoupled UI application
• provide XML/JSON serialized transport to REST Resource without any effort, with proper content negotiation (XML was kept as “Plan B”)
• make our REST Resources as Plexus components (to enjoy all the benefits of IoC, and later pluggability)

While we fulfilled much of these goals above, we did that at a high cost.  For a Nexus core developer (or Nexus plugin developer), it is very cumbersome to create a new REST Resource using our classes, compared to what REST libraries are available today. Current state-of-the-art REST libraries make our initial implementation seem somewhat naive (hence the need to move toward new libraries like Enunciate). Our 1st and biggest mistake was a very deep class hierarchy in our current API.  While all the “defaults” are properly configured, it is often difficult to create a non-trivial Resource in the current API if you are not intimately familiar with the system.

Also, in the initial design, we use XStream with a custom driver to produce JSON. Back then, it was a real pain to produce proper JSON out of Java.   Today, we have libraries like Jackson.   In the next interation of refactoring, you’ll see update the infrastructure used to produce our REST services to bring it up to speed with what is available today.

The Benefits of “enunciating” a REST API

At first, we will use Enunciate with Nexus during build time only, to generate HTML documentation of our REST API. This documentation will be available publicly, but will also be bundled with every Nexus instance!   Our work to modify our own REST infrastructure is going to require some “invasive” work, but I have to emphasize that Enunciate is not invasive if you use it on a modern JSR311 based REST applications. Enunciate is invasive for us only, since we are about to use it on a home grown, non-JSR311 REST application.

Enunciate gathers and builds your services model using your sources and all the metadata it finds (Java5 annotations, Javadoc).  To “enunciate” the Nexus REST API, we had to add JSR311 annotations to our existing REST Resources.  There was one more problem to solve: our method signatures are more “servlet like”, and they didn’t fit the model of a JSR311 REST Application. While a JSR311 application method signature completely describes the method expectations about payload, parameters, and response type, our methods – whether GET, PUT, POST or DELETE – have almost same signature: RestRequest, RestResponse, Variant. Hence, we had to add more metainformation describing what a method does: what it expects as input, if any, and what it sends out as response.

Luckily, it turned out that this was the only piece missing, and Enunciate was happy to generate documentation for us. Ryan added the new annotation that describes the “alternate REST Signature” of the method, and Enunciate got all the information it needed to generate documentation for us.

Another painful step yet to be completed is “freeing” our REST DTOs from Modello. Initially, we knew we wanted to version the DTOs used in REST. Hence, we used Modello to generate the DTOs. Later, problems with Modello and Restlet forced us to always use version 1.0 of our REST DTOs. Since Enunciate requires that DTOs have JAXB2 annotations, we decided to store our DTOs as code and ditch Modello in our builds.

All this looks like a lot of work, but it is actually pretty straightforward.   While this might seem dull to someone not developing Nexus, this work is going to bring real value once it is completed.    In addition to solving our documentation problems, Enunciate is going to open up a world of possibilities once we migrate our REST services over to the framework.

For more information about Enunciate, the Enunciate Wiki contains a nice example of how to use Enunciate in case like ours is, without JAX-RS. Example is shown here.  Examples of Enunciate generated documentation can be seen on it’s site. There is a great walk-through, with static examples.

Expect More Changes in the Next Few Months

As Nexus graduated from alphas, betas and now is at a 1.5.0 version, we realize we have to change gears to keep up. Enunciate is the 1st “newcomer” technology to Nexus stack.  There will be more to come.   Think of this as the Nexus 100,000 mile checkup.  We’re taking a look at the stack and taking this as an opportunity to upgrade where necessary.

One last note, this post is not about any deficiencies in Restlet.  Restlet is a great framework, and it served us well.  We – the Nexus Project team – are very thankful to Restlet.org project with all the help we got from them and for the great library they made.

This video was used as a demonstration reel at January’s Jfokus 2010 in Stockholm, Sweden. It provides a useful walk through of the major features of Nexus Security, including user roles, groups, and privileges. If you are new to Nexus, or if you are evaluating the tool, this five minute video gives you an overview of the UI used to manage Nexus Open Source security.

Highlights of this demonstration of Nexus Security: