With Nexus Pro you can track your exposure to security vulnerabilities and licensing issues. With Nexus Pro you gain control over your releases so you can place release candidate binaries in a temporary staging repository while QA tests and qualifies a release. With Nexus Pro you can control which OSS components you allow into your organization with Procurement. You can proxy the most popular source of components for Java developers (Central) alongside the most popular source of OSS components for .NET developers (NuGet Gallery). If you have distributed teams you can set up two Nexus instances and setup a Smart Proxy so that your distributed teams are always working with the latest artifacts in a distributed environment.

This impressive list of features is only available to you if you can sit down and evaluate these features and come to your own conclusions. Some of our customers take the time to go through the motions of an evaluation, but many are asking for an easier evaluation experience. In the 2.0.5 release, we’ve done just that.

A few months ago the engineering team took a long look at Nexus Professional from the perspective of a new user. What does it take to get started? What were the assumptions we were making about what users know before they download the product? And, how can we make it easier to evaluate the product?

After this exercise it became clear to us that we needed to make sure our Nexus Professional trial bundle contained a few preconfigured features along with a set of simple example projects.

Put simply, it has to be easier to evaluate the product. Our new Nexus Professional bundle “forward deploys” the following features:

• Nexus has been preconfigured to download the search index from Central. Download Nexus Professional and give it a few minutes to download the index from Central . Once downloaded, you can start searching for artifacts. Since Nexus Professional adds valuable information to the search interface, we wanted to make sure this data was available immediately without asking users to click through a flurry of configuration screens.
• A Staging profile has been configured to demonstrate release management. Since Staging is a primary draw for many of our customers, this version takes a step toward making it easier for a first time user to understand Staging. A Staging profile has been configured, and a sample project has been configured to stage an artifact to this profile. A new user can deploy and release via this Staging profile without having to run through pages and pages of introduction and configuration instructions.
• Procurement has been preconfigured so you can quickly define rules for the OSS components. If you need to control your OSS components, this Nexus Professional trial bundle creates a procured repository and adds this repository to your Public group. If you need to start procuring artifacts, Procurement is up and running.
• Nexus proxies NuGet Gallery so that you can quickly evaluate support for .NET development. This is one of the most important changes. Our Nexus Professional bundle ships with no .NET repositories configured and we were asking users to jump through pages and pages of instructions. With this trial bundle, NuGet Gallery is proxied, a new NuGet hosted repository is available, and these two repositories are combined into a NuGet group. To start using Nexus for .NET all you need to do is copy the NuGet API key into Visual Studio for authentication.

In addition to these configuration changes to our Nexus Professional trial, users can now download two simple Maven projects that are preconfigured to download and deploy artifacts from and to a local Nexus Professional instance along with a short evaluation guide to walk you through the process. Download Nexus Professional today and get started.

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.

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

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.

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.

Highlights of this demonstration:

Hightlights of this video:

Highlights of this demonstration reel:

Highlights of this demonstration reel:

Nexus OSS Core has more than 120 REST Resources

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.