• User Tokens – Developers who need to authenticate against a Nexus server can now make use of user tokens. This is a pair of authentication keys which can be used in your settings in lieu of storing a plaintext password. Storing a plaintext password in a build has always been a bad idea, and this new version of Nexus lets you access Nexus securely.
• Advanced Staging Capabilities – Our Engineering team upgraded one of the most popular features of Nexus, the Staging capability. With this newly improved staging subsystem your staged releases now benefit from a range of advanced features, such as atomic deployments and closer integration with Nexus REST services. This feature is an implement in Nexus Professional as a Maven Staging plugin.

Evaluating Nexus Professional just got a whole lot easier

If you are evaluating Nexus Pro, you’ll benefit from an easy to use installer, which was designed to automate the installation, configuration and set of Nexus on Windows, OSX and Linux. With this new installer, users are able to customize where Nexus will be installed and what port Nexus will be configured to listen on. This installer will even automate the setup and configuration of a set of simple evaluation projects. It has never been easier to get started with your Nexus Professional evaluation. Download a Nexus Professional trial and get started.

Nexus OSS 2.1 – Security and Bug Fixes You Need

Nexus OSS 2.1 has approximately 102 bug fixes – everything from an upgrade to Jetty 8 to security fixes. Nexus OSS 2.1 is faster, more secure, and more stable thanks in large part to our Insight product. Engineering ran the Insight report against our own software and identified some critical security bugs. If you are using a previous version of Nexus 2.0 (or if you are using an earlier version of Nexus 1.x) there is no good reason not to upgrade immediately.

Go download Nexus OSS 2.1 and start your upgrade.

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 will be moving data centers and want to setup another Maven2 repo that is managed with Nexus OSS. We want both repositories to be online and read\writeable until we migrate all our environments to the new site. I have a few questions:

1. What is the best method for copying the repo to the new location?
2. What is the best method for keeping the two repos in sync? We want to minimize network bandwidth usage.”

The video below answers these questions, and offers multiple solutions:

In this post, I’m going to talk about some recent changes to Nexus that will help you distribute Maven Archetypes, and I’m also going to offer some strategies for when you should start to think about using Maven Archetypes to support development.

Distributing Maven Archetypes with Nexus

While Maven Archetypes provide a clean way to create a new project, I fully understand and accept that many of us copy, paste, and modify existing POMs into new Maven projects. The issue with Archetypes up until this point has been one of distribution. Once you create a Maven Archetype, how do you publicize it? For years, there was no great answer to this question, you had to tell people about an explicit set of coordinates and you also had to tell people to run a long, ugly looking command-line.

A few years ago, Sonatype created the Nexus Indexer and now users have a much easier way to list available archetypes. If your Archetype ends up on Maven Central, it will eventually make its way into the list of available archetypes in m2eclipse or when you run the Archetype generate goal. Instead of telling people to execute a difficult, longish command line, just tell them to fire up m2eclipse and search for the archetype by groupId or artifactId.

What about internal archetypes on your own repository? The latest version of Nexus OSS has a solution for that? We’ve added the Nexus Archetype plugin as a core plugin. This means that you can start to benefit from the same distribution mechanism for your own, internal archetypes. If you use an internal Nexus repository, you can point your Maven clients and m2eclipse IDEs to this instance and see a catalog of Archetypes which will include your own archetypes.

When to Use a Maven Archetype?

Open source projects and libraries.

Using a Maven Archetype you can capture the skeleton of a project and include some sample code that can be customized. If you are creating some open source framework, say a web framework, or a new way to interact with a database, you should be publishing a set of Maven Archetypes. Projects (and companies) can reduce the amount of effort needed to integrate technologies by publishing archetypes to Central. If you need to create a plugin for Confluence or JIRA, it is easy, just use the JIRA plugin archetype. Need to write an AppFuse application, don’t invest a few hours figuring out what dependencies you need and what the suggested project structure is, take a short cut and fire up an AppFuse archetype.

While some projects realize this, I still think there is a lot of unclaimed territory. Some examples that stand out are the myriad of NoSQL products with Java APIs. A project like MongoDB would bring itself much closer to the developer audience by publishing ready-made Archetypes to central. I could list out a hundred more projects that would see more wider adoption with a Maven Archetype, and I’ve made it one of my own goals to try to get more projects to see Maven Archetypes as an essential part of developer community support.

When to Use Archetypes for Internal Projects

For internal projects, the value of using a Maven Archetype is up for some debate. For example, if you are working on a collection of web applications and you need to create a new one, you have two choices. You can:

• Copy the existing project to a new directory, change some identifiers and modify your code appropriately. This option is entirely acceptable for a medium-sized workgroup. If you are working on a manageable piece of code, creating a Maven Archetype just to save a few minutes of duplication and effort makes little sense. It is OK to copy, paste, customize sometimes and you shouldn’t view Maven Archetypes as a requirement if you have a few projects that duplicate structure and POM configuration.
• Create a new Maven Archetype which captures the core structure and configuration of your project and just seed a new project from this archetype. If you work on a library or framework that has internal customers. For example, if you work on a web frameworks group on a larger project and your internal “clients” are creating new projects, you will certainly want to think about creating a set of internal Archetypes.

Clearly there is a time to use archetypes and a time to just copy and paste projects. If you are only creating a handful of projects over the course of a multi-year project, then you might just opt for the simple copy and paste approach to project expansion. If your project frequently creates new projects, and if these projects all have a common structure, you will likely want to create a new Archetype to capture the common pattern.

In Organizations “of Scale” Archetypes are Essential

Sonatype very frequently talks to organizations that program systems on a world-wide scale. Large banks with thousands of developers all working within a common framework developed by an architecture group. In these situations, internal archetypes don’t just make sense, they become a necessary part of doing business. When you have multiple departments creating new architectures, sharing code, and creating APIs for one another, you will need to define structures and standards for projects and builds.

Why? The most common inefficiency we’ve seen is an organization that lacks strict standards for project builds. We’re not just talking about POM structure here, we’re talking about the organization that has ten critical subsystems managed by separate teams each with an individual idea of what the build is for. One team uses Ant, another uses Maven, and yet other teams decide to create custom frameworks.

If your organization has problems integrating multiple, disparate builds into a single working system, you probably need to start thinking about standardization. While Maven provides a baseline of standardization in the form of POM structure, dependencies, artifact coordinates, and repository management, defining a set of Maven Archetypes as “enterprise templates” will help to define how projects are created and managed.

In summary, Maven Archetypes are more than just simple example templates to be used with open source projects. You can leverage the power of Maven Archetypes for your own, internal development, and you can use the newly release Nexus OSS to make it even easier to distribute these templates to your own internal users.