Sometimes Releases are Disposable

For example, consider a company that creates a large web-based system. They may deploy new versions of components to production multiple times a day. If this seems unrealistic, know that system administrators for popular services like Facebook, Last.fm, and Flickr have talked openly about how frequently code is pushed to production systems. A few times a day isn’t odd in some of these environments, and with a large system, you’d consume terabytes of space to keep all of those old releases around.

Last time I worked at a large consumer-focused web site, pushing something to production once a day wasn’t uncommon, and even the idea of rolling back to anything other than yesterday’s build was laughably impractical. If you identified a bug in a CMS or a production database, you’d just craft the fix it and move on. This is especially true of larger, web-facing systems in which the only reality is the code that is running in production today. A site like Flickr gains nothing from being able to roll back to a release from last September.

The Other Side of the Coin: Releases are Forever

Compare this to the production release schedule of a critical, supported product and it’s like night and day. If you are coding some serious banking system you might be lucky to have a release once a month. In all likelihood you might be looking at a quarterly release.  When you are working on critical applications, ship software, or have infrequent release cycles then the ability to roll back to previously released binaries is very important. When you work somewhere fast-paced with a very short release cycle, there’s not much value in retaining older releases.

For this reason, we’re clarifying this point: if it makes sense for you to delete release artifacts from a hosted repository, go for it. Just remember to re-index the server once you’ve manipulated the storage folder.

We put together the following video to share more of our thoughts on this topic.

At Sonatype, we want to make synchronizing and publishing your artifacts to Central easier and to improve the quality of repository metadata for everyone at the same time. To facilitate this, we offer a dedicated instance of Sonatype Pro for Nexus at http://oss.sonatype.org specifically to host the artifacts of open source projects. In this post, I talk about the process of creating a repository for your open source projects and publishing artifacts so that they will be available from the Central Repository.

This service has been available since 2009 and includes many projects such as Plexus, Jetty, Google Guice, Spring and Ehcache (Greg wrote about his experience with migrating to oss.sonatype.org). We have tooling in place to make it easy for us to process a larger set of requests, so we invite everyone to use this resource. As of October, 2011, we have over 1,500 projects using this repository on a daily basis.

To get the process started, go here. We’ll setup a release and snapshot repository for your project, along with the appropriate configuration to allow you to use the staging features for your releases. If you have an existing repository somewhere, we can migrate that for you too. We’ll even help you add artifacts to Central that you use, but don’t necessarily own — assuming of course that it doesn’t violate the projects license.

The system allows customizable rules to be run during the staging process, which allows us to automatically check things like valid pgp signatures and correct POM parsing. This will ensure that your users have the best experience possible when using your artifacts, and relieve some of the manual validation on your side — a win for everyone.

On the technical details, this instance gets its network connection via Contegix‘s high availability network, the same one running Central, Codehaus.org and Atlassian.com. New Relic has donated monitoring services to help us monitor and tune this instance of Nexus. Since OSSRH is hosted on the same infrastructure as the Central Repository, we are able to frequently synchronize the repositories.

Next time you need to add a project to the Central Repository, you’ll know how.

While this seems like such a simple idea, the Maven ecosystem hasn’t had a standard way to search the repository for the majority of its history. For much of the last decade there was no reliable way to search for an artifact. In this post, I’m going to review this history and talk about Maven repository search and where we think search is headed. With the release of Nexus OSS 1.9 it is now a good time to summarize the results of Sonatype donation of the Nexus Indexer to the Apache Software Foundation.

In the beginning…

In the beginning there was ibiblio. That’s not entirely true. When Jason van Zyl created the first Maven repository in 2002, there were a number of different servers and mirrors involved, but after a few weeks of migrating between Apache servers, the first incarnation of Central ended up at ibiblio.

If you were depending on the Maven repository back then, you have a good appreciation for how far we’ve come in just a few years. Back then, the bandwidth was terrible and the connections were iffy. It was touch-and-go both in terms of stability but also in terms of process. You can still see some of the echos of the initial effort today in the form of old group IDs. If you are wondering why projects like log4j and commons-lang exist as top-level group IDs it is because the initial artifacts didn’t follow the same strict standards for naming. In 2002 the repository was emerging, and it would take a few years for people to agree on standards and formats.

Maven’s Structure Becomes a Standard

Within a year, people using the Maven repository had come to rely on it as an essential piece of development infrastructure. While Java had been around for almost a decade, no one had created a viable repository structure. There was no way to distribute artifacts between projects, and the Maven repository was created at a critical time in the development of open source Java. As Java really start to take off in the enterprise, as systems grew more complex, and as an explosion of open source Java libraries hit the scene from places like Apache, the Maven repository quickly became the established way to distribute artifacts. There was no going back.

Maven Search: The Dark Ages

Years passed, the format of the repository changed between Maven 1 and Maven 2. As more and more projects started to use Maven or publish to the Maven repository, there was a need to create some sort of search interface to help developers locate artifacts in the repository.

Initial efforts for repository search were disconnected and relied on multiple, independent systems running proprietary analysis on the entire repository. (I know this myself because I took at stab at writing one in 2006.) To search the repository, you had to download the entire repository and run a series of regular jobs to grab changes and update an index. There was no standard search mechanism that would facilitate tool integration, and most people discovered Maven artifacts either by clicking around in a browser or by word-of-mouth.

Earlier Repository Managers and Search

Early repository managers contained independent implementations for search indexing. Early versions of Archiva had an independent index library based on Lucene, and Artifactory relies on a JCR store. While it was clear that repositories were going to play a key role in providing an easy way to search for artifacts by metadata and class name, these earlier approaches still required people maintaining repository managers to download the entire repository and run a time consuming, CPU-intensive process just to create searchable index.

This is where the Nexus Indexer started to come into play.

The Nexus Indexer

When Sonatype created a repository manager, we also aimed to create a standard and sustainable way to search for artifacts. The Nexus Indexer defines a standard format for repositories, but, most important, it defines a portable format that captures information about a repository. This format is what your repository manager downloads from a remote repository, and it is the reason why repository managers like Nexus and Archiva can allow you to browse the contents of a remote repository without downloading “the entire internet”.

Sonatype’s open source repository manager, Nexus, was the first repository manager to define a standard format for a repository index. We didn’t just define a product with a search feature, we set out to define the standard. Using this model, servers like Maven Central and other popular open source forge repositories would periodically index repository contents and present clients with an index. Instead of downloading Terabytes of data from the internet, your Maven client, your IDE, your repository manager could download an optimized index containing all of the metadata about artifacts in the repository.

This innovation also had the effect of offloading the responsibility from your repository manager. If you want to search the repository, you don’t have to set aside a few days for your own instance to crawl Terabytes of data. Maven Central is indexed once, in a central location, and the world saves zillions of CPU cycles because of that fact.

The Nexus Indexer was an immediate success, the index format was created on a weekly schedule on Maven Central. Sonatype carved out the Nexus Indexer as a separate component, released it under a very conservative, BSD-style license, doing all we could to make sure that everyone interacting with the repository could read this format. Very quickly all of the repository managers on the market could both read from and write to a Nexus Index. For example, Archiva now relies on the NexusIndexer, and will likely move to the Maven Indexer.

Donating Nexus Indexer to the Maven Project

As this index format became more widespread through the Maven ecosystem and more generalized for other languages and systems. Sonatype thought it made perfect sense to remove any direct association with Nexus. It was becoming a part of the foundational infrastructure for the community, and, in a decision that might make some executive’s heads spin with disbelief, we donated it to the Maven community. We gave it away.

For something this low-level, this important to the community, it didn’t make any sense for Sonatype to hold on to this resource. The Nexus Indexer is now called the Maven Indexer and the code behind this index is now a part of the Apache Maven project.

At Sonatype, we understand the role we play in supporting the universal infrastructure that enables the world to develop and collaborate. We also understand how important it is to ensure that something as important as the index format be truly open: managed by an active and healthy community, free of difficult licensing questions, and unencumbered by patent concerns.

Next Up: Nexus OSS 1.9, Now with the Maven Index

To complete the circle of our successful transition of the Nexus Indexer to the Apache Maven project, we’re announcing that the next version of Nexus is one of the first projects to incorporate the newly minted Maven Indexer. Stay tuned.

To improve the experience for users in Europe, Sonatype has provisioned a new official repository in the United Kingdom. This is more than a mere mirror of Central, this system is updated in lockstep with the systems here in the US, and is managed and monitored 24×7 by Contegix, the same team watching over the US repositories. The new repository consists of two fully redundant systems running in parallel to provide complete fail-over capacity.

In addition to the new repository, we have taken several steps to improve and further secure Central itself:

• A new system has replaced Central as the inbound processing engine. On this staging system, we can now vet inbound artifacts for quality and other parameters before publishing them to repo1 and Europe. It also serves as a hot standby for the US repository.
• We’ve worked with Contegix to implement additional layered security around the repository machines themselves.
• There is a new Jira project to manage any and all concerns and issues with Central, the Mirrors, Content, etc
• We are working to setup another official Central Repository in Asia soon

The new repository is live at http://uk.maven.org/maven2/ if you’re using a repository manager, just replace references to http://repo1.maven.org/maven2 with the new url. If you’re not, you should be (Whitepapers: Intro to Repository Management / Stages of Repository Adoption), but until you get a repository manager in place, add the following to your settings.xml:

<mirrors> <mirror> <id>uk</id> <mirrorOf>central</mirrorOf> <url>http://uk.maven.org/maven2/</url> </mirror> </mirrors>

Some additional coverage on this topic can be seen at InfoWorld, BusinessWire and InfoQ

First, the how, what, and when of a continuous integration server. Continuous integration (CI) servers are an established fact of of modern development infrastructure. It is a server which, for the most part, waits and watches. It keeps a vigilant eye on your source control system and jumps into action every time it sees a code change. When code changes, your CI system is usually configured to run the entire build, execute all of your unit and integration tests, and send out an email to every developer if it identifies a defect or a failed test.

It does this so that you will have an easier time identifying where a particular problem was introduced to the source code. If John checks in some bad code, the CI system runs the build immediately, and about 30 minutes later, everyone in the group receives an email with the subject header “John just broke the build”. It is a great way to identify errors, and it is also a great way to motivate developers to test locally before committing to a source control system as no one likes to be the reason for a build failure email.

Running a CI server is more than “just a good idea”. Once your system reaches a certain level of complexity you can’t scale a system without commiting to continuous integration and testing. If you don’t have continuous integration, you end up having to put all development on hold each time you want to perform a release. If you don’t build, test, and deploy your system on a regular basis – if it isn’t something that is well rehearsed, integration becomes a time consuming nightmare of manual testing and builds that often leads to inconsistent builds. This is especially true if your development effort spans multiple systems and multiple development workgroups. You run a CI system because building, testing, and deploying your system should be automatic: it should be as trivial as pressing a button.

The concept of a CI server is only slightly more established than a repository manager, and very often you will see that an organization has identified the need for a CI server before they’ve identified the need for a repository manager. If you are coding a complex system, there is a very good chance that you are already running a CI server. The most popular servers out there are Hudson, Bamboo, and CruiseControl. While the connection between CI servers and repository managers might not be immediately obvious, when used together they can introduce some new possibilities for the way you develop your systems.

Continuous Publishing

When you have a system to continuously build your code, you also have a system that can continuously publish SNAPSHOT artifacts to a repository manager to enable a more granular approach to development. What do I mean by “a more granular approach to development”? To answer that question, let’s take a look at a complex multi-module project using the example of the eCommerce group from the previous post in this series.

Assume you have a new programmer starting tomorrow. Instead of throwing him at the entire forty-thousand lines of code, you would like to be able to give that developer a small, easy to digest task. You want this developer to add support for PayPal’s Adaptive Payments API in your eCommerce system. That’s it. You don’t want them to be distracted by the overwhelming scope of the project, and you certainly can’t afford for them to take a three month voyage through your project’s code before they start contributing to the effort. Deadlines are tight, and you don’t have enough people on your team. It is important that new hires start programming as soon as they walk in the door.

Without a repository manager hooked up to a continuous integration server, if you try to checkout just the ecom-paypal project, the build is going to fail because it will try to download dependencies from a repository manager. In the case of the ecom-paypal project, assume that the dependency graph looks like this.

When you have a repository manager and a continuous integration server, you can configure your continuous integration server to publish SNAPSHOT artifacts (in-progress SNAPSHOT binaries) to your repository manager. This will allow you to just check out a single, isolated portion of a much larger multi-module project.

Without a repository manager, trying to build version 1.3-SNAPSHOT of ecom-paypal in isolation is going to generate errors because you are forced to checkout the entire codebase to build and install all of the dependencies in your local repository. With a repository manager, SNAPSHOT artifacts are being continuously published because Hudson is checking you SCM every few minutes and building the latest code. When you run the ecom-paypal module’s build in isolation, Maven is going to download the most recent SNAPSHOT.

Without a repository manager, your new developer is going to have to download the entire codebase and run a large time-consuming build. With a repository manager you can work on specific components of a larger multi-module project. This ability to divide and conquer your codebase comes in very handy when you need a consultant to take a look at a specific problem, or when you need to look at a coding problem in isolation.

When you continuously publish build artifacts to a repository manager, you move away from the single monolithic project build and toward a project layout and architecture that lends itself to modularization.

In tomorrow’s post: How a Repository Manager decouples deployments from source code, and what that means for developer operations.

Aether (pronounced ē’thər, as in flying though the ether) aims to be the standard library for interacting with Maven repositories. Without question, the most important aspect of the Maven ecosystem is interoperability at the repository level. There are many emerging options in the build space for JVM-based languages, but the one thing they all have in common is their interaction with Maven repositories. It’s clear that Maven repositories play a critical role within JVM-based development infrastructures and Aether will provide the necessary interoperability, through a common set of tools and APIs, that’s critical for happy users in the ecosystem.

Aether & Maven 3.x

Benjamin Bentmann, Sonatype’s lead on Maven 3.x, has fully integrated Aether back into Maven 3.x. Though Aether is an extraction from Maven, Aether is not Maven specific. That said Maven 3.x and Maven repositories are our first priorities. The upshot is that if you embed Aether, you will be embedding the same library that Maven 3.x uses when it interacts with a Maven repository. If compatibility with Maven repositories is important for your project then it’s not going to get any better than Aether.

Aether & Mercury

Mercury was our first attempt at extracting a Repository API from Maven and that didn’t work. We bit off more then we could chew, and so our first attempt was a learning experience. We attempted to integrate the excellent SAT4J library but didn’t have enough experience to pull that off. In addition there may be features of SAT4J Maven requires that are not present yet. As such, we felt it better to attempt something less ambitious, yet functional, and invest in research for future improvements.

Aether, p2 & SAT4J

As part that investment, we will be collaborating in sponsored research with Daniel Le Berre, who is the author of SAT4J. Daniel is a tenured professor at University of Lens, and researcher at Centre de Recherche en Informatique de Lens and is affiliated with Centre National de la Recherche Scientifique. His work will not only help us with p2, but also with many things we want to accomplish in Maven. We see a lot of overlap in the work Sonatype is doing on Maven and p2 and ultimately we really see there being one artifact resolving framework.

Aether & Ant

Rest assured there will be excellent Aether Ant Tasks. Making sure that Aether works flawlessly inside Maven 3.x is our first priority, but we are committed to making a set of excellent Aether Ant Tasks. If you’re interested in Aether Ant Tasks you can follow the progress here.

Aether Resources

If you are interested in Aether here are the goods:

• Aether Sources @ Github
• Aether Issue Tracking @ Sonatype
• Aether Wiki @ Sonatype
• Mailing lists:
  • Aether Users @ sonatype.org
  • Aether Developers @ sonatype.org
  • Aether SCM @ sonatype.org

P.S. Thanks to Pierre-A Grégoire for the name Aether!

Better maven support has been frequently requested on the issue tracker and mailing list, and this is a first step in that direction. In the future, Google will publish GWT releases to maven central as part of the release process.

The GWT 2.0.4 jars currently in the repository include gwt-user, gwt-dev, and gwt-servlet.    To publish these artifacts in the Maven Central repository, Google publishes artifacts to Nexus OSS, the Open Source oss.sonatype.org repository.   You can see the Google-specific repository on this server here.   Releases are staged to this Google repository on oss.sonatype.org and then subsequently released and synchronized to the Maven Central repository.

Configuring the GWT Plugin

To start developing with GWT, take a look at the “Automatic Mode Setup” section on the GWT Maven plugin’s Setup instructions.   Before last week, the only way to develop a GWT application with the latest version of GWT was to download the SDK to your workstation and then use systemPath dependencies or a custom task to publish artifacts to your local repository.    Today, you can just point your Maven project’s pom.xml at the correct version of gwt-servlet and gwt-user and Maven will grab the necessary native libraries from Central.

This doesn’t just make GWT development easier and more straightforward for people already using the tool, it will make it much easier for developers to start using GWT.   When you publish your project’s artifacts to the Maven Central repository you make it easier for people to adopt your technology.   Maven Central is the “dial tone” for most developers, and if you put it on Central, they can access it without having to download an SDK or configure a build system.   Maven Central just works.

Nexus OSS is the fastest, most efficient way to publish artifacts to Maven Central, and Sonatype has made this service available to any open source project that needs to publish artifacts.   If you work with an open source project or a company which publishes open source libraries, read the Sonatype Nexus OSS Repository Guide to get started.

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.

Sonatype is focused on improving the foundational infrastructure which will allow us to improve the quality of artifacts and their accompanying metadata in Maven Central and Maven repositories around the world.  A lot of this is not especially glamorous work and though many people complain about the state of some of the Maven repositories, very few take action.    Here are some of the things Sonatype is doing with Nexus to improve the state of the Maven ecosystem and expand its scope.

Improving the Quality of Public Maven Repositories

Any effort to improve the quality of the Central Maven repository needs to begin with the major feeder repositories.  For years, we have been giving rsync access to many of the organizations with large feeder repositories like Apache and Codehaus.   When we started this effort, we were optimistic that these organizations would take care of their Maven repositories.   We thought that repository maintainers and projects would make sure that all artifacts were signed and that all POMs contained a bare minimum of useful elements such as “license” and “description”.    With hundreds of projects pushing artifacts into their respective repositories on a daily basis, it has become obvious that without some mechanism to guarantee quality, without a well-defined process, the Central Maven repository will contain artifacts and metadata of questionable status.  While the vast majority of artifacts have appropriate PGP signatures and metadata, the fact that a minority of (often very popular) artifacts lack proper dependency definitions or license elements means that we see a steady stream of complaints about the quality of the repository from our users.

These problems can be anything from one project trying to publish another project’s artifacts because they weren’t in Maven Central, incorrect, bad, or missing metadata, missing javadocs or source JARs, to invalid transitive closures.  Whatever the problems are, the overall issue stems from the lack of process surrounding how artifacts are published to our feeder repositories, and how these artifacts are then certified to be published to the Central Maven repository.

Sonatype’s answer to this problem has been to provide tools that can automate the process of repository maintenance for Central’s largest customers – the main feeder repositories.   We’ve provided a solution to the largest of the feeder repositories which allows them to use the Nexus Staging Suite to validate that all release artifacts contain the bare minimum of metadata, javadoc, and a valid PGP signature.    As Ate Douma wrote in Monday’s post about using the Nexus Staging suite to support the Apache Portals project, we’ve supplied a solution that reduces the amount of error-prone, manual work associated with software releases, and we’re going to continue to find ways to address the needs of large, open-source enterprises with Nexus by providing Open Source projects and organizations with a free license and free support.   Here is a list of some of the organizations with large feeder repositories that we are supporting directly:

• The Apache Software Foundation
• Codehaus
• Alfresco
• ExoPlatform
• Glassfish
• Open QA
• Scala-Tools

With all of these organizations and projects using the Nexus Staging Suite, we are confident that the quality and reliability of artifacts and metadata will increase over time.  The PGP signatures provide the security assurances organizations need, and the sources, javadocs and correct POM information like SCM information make for a better developer experience in the IDE.  In M2Eclipse, for example, javadocs and sources can be dynamically retrieved as required and binary dependencies can be materialized to source from from SCM coordinates. This makes contributing patches to an dependent project an order of magnitude easier.

We are also fortunate to be working closely with Atlassian. We have Atlassian Crowd support in Nexus, so Nexus is an ideal fit for Atlassian and for organizations that make use of Atlassian’s compelling products. You can find Atlassian’s Nexus instance here. It’s just another validation point for us that Atlassian sees fit to use our products as part of their daily development. We have a lot of respect for the Atlassian folks, and we’ve standardized our entire development environment on tools like JIRA , Greenhopper, and Confluence.

Decreasing the Time to Reach Maven Central

Many users and projects have complained that it can take a while to get their artifacts in Maven Central so we’re starting to focus on reducing the time to reach Central. The biggest obstacle to automating the process of publishing artifacts to Central is one of quality.   Artifacts would reach central faster if there was a better way to enforce a minimal set of quality standards.  The legacy process involved projects uploading “bundles” to a JIRA project and repository maintainers manually inspecting the bundles to see if they complied with a set of standards.

In the previous section, I described how Nexus is already powering the major feeder repositories for the Central Maven repository.  What we offer projects is described here. Basically we will help you cleanup, and migrate your project’s Maven repository to our hosted infrastructure and help you setup your project POMs to use Nexus’ Staging. Projects are setup with the default staging rules which ensure the presence of PGP signatures, javadocs, sources, and a POM which contains decent information. We provide all the instructions for the setup on the Maven side so there is little work you have to do in order to take advantage of this service.  We are also providing a mechanism by which the standard bundle uploads, typically done via JIRA, can be handled by Nexus. Internally within Nexus the upload bundle is exploded and placed in a staging repository, as would happen if you performed the release against Nexus from your Maven build.  We then apply the same staging rules to ensure quality.

We have already started rewarding projects with good Maven releases by automating their synchronization with Maven Central.   Over time we are going to start enforcing standards for security and quality of metadata.    If you have proper project metadata, PGP signatures, javadocs and sources your artifacts will fly into Central as quickly as possible.  Projects that submit poor Maven releases are going to have a more difficult time getting artifacts into Maven Central.   We’ll start to enforce these standards gradually and we’ll give the community time to adapt.  Any tool that creates bundles for deployment to Central is capable of producing these artifacts. The staging rules don’t care how the releases were constructed. So use whatever tools you like, you’ll just have to pass a minimal set of requirements to make it into the Central repository. Over time this should greatly improve the quality of Maven Central.

Providing Metadata about Repositories

For a long time we have been providing a way, through Nexus, and the stand-alone Nexus Indexer, to produce the Maven repository index.  The repository index contains information about all the artifacts in the given repository including class file information and project identifiers.  It is primarily used as part of IDE integration to help developers find dependencies based on artifact coordinates or class references, like import statements.   Using m2eclipse, all you need to do to add a new dependency is type the name of a class into your code and search the index for matching dependencies.    You can also search the repository index for all of the available Maven archetypes when you are creating a new Eclipse project.    Both of these IDE use cases are possible because of the standard repository index format that was defined as part of the Nexus project.

The Nexus index format is also storing information about the presence of PGP signatures, javadocs, sources, and checksums.   Using Nexus and other tools that can read the Nexus index format, you can aggregate multiple repository indexes together and perform quick searches across multiple public repositories (as well as your own hosted repositories). The Nexus indices from the OSS repositories around the world are proving to be a critical resource, we can tell because it is the most requested item from Maven Central.  Index downloads amounted to 28TB of transfer last month.

Polyglot Component Repositories

The explosion of language choices has transformed the way most developers approach problem solving.   Just four years ago it would have been normal to walk into a corporation and see Java at all levels of the stack.  In 2010, most businesses have started to incorporate multiple languages and hybrid architectures into enterprise systems.   A system designed today might use Ruby on Rails (running under JRuby) to power a web site which interacts with a set of services coded in Java.  Services like Twitter rely on a foundation of Scala code executing on the JVM while other portions of the Twitter architecture use different languages and different technologies where they are most appropriate.

We are a polyglot industry, and while our software enterprises are run on a mixture of different languages, our development tools and build technologies are often locked into a single language or a single technology.   A Ruby application is built using Rake, a Scala application is built using Sake or the Maven Scala plugin, and Java or OSGi applications are built using Maven.   A Ruby library might generate and consume gems while a Java application might generate and consume JAR files.   There is currently no single, consolidated “Tower of Babel” to help developers translate between different types of software artifacts.   We’ve put a lot of effort into making the foundation of Nexus as agnostic as possible about what it is storing, and, because of this, we’re moving to add support for even more artifact types.

Nexus currently supports the two OSGi formats of P2 and OBR and we are just finishing our first draft of RubyGems support.   Polyglot Maven will drive us toward a Polyglot Nexus. As part of the work we’re doing on Polyglot Maven we may find that different scripting language implementations have slightly different requirements for dependency management or provisioning runtimes, and we’ll be ready for that.

Where do we go from here?

Next we’re thinking about ways to make statistics for a given project’s artifacts available to the project’s developers.  We have already implemented user signup in Nexus and we are currently working on project signup as well. What this means is that projects can register with a given groupId, or set of groupIds, and optionally be provisioned a repository which can be operated by a set of users. Once a project registers we will know what slice, or slices, of the statistics they need to see.   Our initial thought is that project statistics, number of downloads should only be made available to the public with the permission of each individual project. Brian and I along with Greg Luck and Dain Sundstrom have been working on a simple statistics mechanism that we hopefully can provide to projects early this year.