With nearly 19,000 active instances of Nexus around the world, we thought we would reach out and ask the community to share their Nexus stories and experiences with us. Over the last six weeks we held our Nexus Stories Contest and we were blown away by the tremendous response we received from around the globe.

Thank you to all of you who took the time to participate. We hope you are all enjoying your wicked awesome Nexus mugs! As promised, we will be sharing your Nexus stories on our blog over the coming weeks.

After the overwhelming response we received, we decided drawing one grand prize winner just wasn’t good enough (plus we love to take advantage of Jason every chance we get). So we decided to draw three grand prize winners!  Our three lucky winners will each be receiving one day of onsite consulting with Jason van Zyl. Our grand prize winners are:

• Alexis Morelle, Colombes, France
• Rueben Jimenez, San Francisco, CA
• Henry Hughes, Los Angeles, CA

Congratulations to our winners and thanks again to everyone who participated!

Stay tuned next week, when we will be sharing some of your stories on what life was like, before Nexus.

Sonatype makes it easy to add your projects to the Central Repository with a free, public hosting service called OSSRH, that we recently wrote about here.  Many developers have found this a very useful service and easy to use with Apache Maven.  However, if you’ve started using Gradle, you may have wondered if you could continue using the service.  The answer is absolutely YES.

We were talking about creating a guide for this, but someone in the community beat us to it.  Yennick Trevels published an excellent guide in his blog that you can find here.  We highly recommend checking out his post if you want to use Gradle to deploy artifacts to the Central Repository.

Sonatype’s perspective regarding the Hudson Project is pretty simple: we have been and will continue to be committed to advancing Hudson and making better software available to the community of Hudson users.

Very recently, Sonatype completed significant development in the evolution of Hudson’s core architecture. The benefits of these changes include better leveraging of industry standards, increased performance and stability, and tight integration with Maven 3 that provides greater visibility into running builds. We are continuing to add engineers to our Hudson team and are working hard with the Hudson community to move much of the work we’ve done here to Java.net.

Our work on Hudson is consistent with Sonatype’s long history of investment and community support. Our work with Maven at the Apache Software Foundation, with m2eclipse at the Eclipse Foundation, and with Nexus (our open source repository manager) all underscore our commitment to innovation for open source and commercial users alike.

Are we a commercial enterprise? Absolutely. However, our track record of open source innovation and community contribution speaks for itself. At Sonatype, we’ve always focused on the code, and that’s where we’re focused today with Hudson.

For my talk today at JFokus today I’ve taken the liberty of starting some notes for folks interested in attending. There’s a lot to cover and so I thought I would try the approach of providing some material up front so the session can be more of a dialog. I’m going to attempt to cover everything in the picture below and save the demos folks might want to see for the Sonatype booth. Happy to chat with folks and do any demos before and after the presentation. Just stop by!

Maven Stack Infrastructure

I’m going to talk about some of the under pinnings of the technologies we’re using as part of our Maven work. Why we selected the technologes and some of the current work that’s happening.

• Guice
• From Plexus to Guice (#1): Why Guice?
• From Plexus to Guice (#2): The Guice/Plexus Bridge and Custom Bean Injection
• From Plexus to Guice (#3): Creating a Guice Bean Extension Layer
• Peaberry
• Apache Shiro
• Enunciate

Maven

There are several develops going on in the various Maven projects. Maven 3.x is on the way, but we have some very interesting work happing with OSGi within our Tycho project. The Flexmojos project and NAR (the C/++ framework for Maven) are also popular.

Tycho

• Tycho Site
• Tycho @ Github
• Tycho/PDE Integration
• P2 Site

Flexmojos

• Flexmojos Site

NAR

• NAR Site
• NAR @ Github

M2Eclipse

The primary IDE integration we work on at Sonatype. The most important thing to talk about in M2Eclipse is the configuration framework.

• M2Eclipse Site

Hudson

Most of the work we’ve been doing on Hudson is still not really good enough for public consumption but we’re testing the changes we’re making on the Sonatype grid.

Hudson Site

Nexus

• Nexus Site
• Nexus: Improving Maven Central and Supporting the Maven Ecosystem
• Selecting OSS Software: 10 Questions Answered for Sonatype Nexus
• OSS Repository Hosting
• OSGi Central
• Ruby Central (We’re working on making that publicly available

Proviso

Proviso is not publicly released yet, but Alin and I have been working together to get our provisioning framework ready for a public release.

Git

We are starting to use Git heavily and soon likely exclusively. We are helping out on the EGit, and JGit projects at Eclipse and we’re trying to put a little Git server together based on JGit, MINA, and Apache Shiro.

• JGit Site
• EGit Site
• Tycho building EGit/JGit
• SShJGit @ Github

Maven Extensions

I’ll chat about these in the talk.

• Polyglot Maven Site
• Polyglot Maven @ Github
• Maven Shell
• Maven Shell @ Github

I’ll likely keep adding to the entry leading up the talk, but I thought I would get the ball rolling!

Having used Nexus since it was a beta release and having also written a Plexus component-style Nexus plugin (the nexus-ldap realm), I was curious about the new Nexus Plugin API introduced in Nexus 1.4.0. To try it out, I asked two of our developers here at Devoteam Sweden to develop the Nexus Remote Repository Browsing Plugin – a Nexus plugin that makes it possible to directly browse the remote Maven repository of a proxy repository within the Nexus UI. The plugin has been contributed to Nexus OSS and will be released as a part of the upcoming 1.5.0 release.  In this blog post, I will talk a little bit about the plugin and its use case.

In the Repository panel of Nexus, there are two tabs for browsing artifacts. The first one is called “Browse Storage” and is used to browse all artifacts stored/cached locally by the Nexus instance. For a hosted repository, the tree displayed under “Browse Storage” will contain all available artifacts. For a proxy repository, you will only find those artifacts that have been cached due to earlier requests. The second tab, “Browse Index”, allows you to browse artifacts through the repository’s index.  If the remote repository provides an up-to-date index and you have configured Nexus to download this remote index, all of the artifacts in the remote repository will be visible under the “Browse Index” tab.   While the “Browse Index” tab works for all of the major public Maven repositories, it doesn’t allow you to browse remote repositories which do not publish a Nexus index.

This is where the Nexus Remote Repository Browsing Plugin (nexus-rrb-plugin) comes into play. The plugin adds a third browsing tab for proxy repositories, the “Browse Remote” tab. In this tab, it is possible to browse the actual remote repository from within the Nexus UI. Below you find a screen shot of the new tab.

Before this plugin, the user was forced to browse the remote repository in a separate browser window. Not only is this inconvenient, but for many users it is not possible as the URL of the remote repository is normally only visible to administrators. Also, the connection to the remote repository will be initiated from the Nexus instance. The benefit of this is that it will work even if your network setup prevents direct access from the clients to the remote repository.

This first version of the plugin doesn’t add any bells and whistles to the browsing. The tab is added to all proxy repositories and is available to all users. However, it does support browsing of Maven repositories at S3, such as the SpringSource repository.  This ability to browse a repository hosted on S3 is significant as it is tricky to do this via a normal web browser.

As mentioned above, the nexus-rrb-plugin is included as a core plugin in the upcoming Nexus 1.5.0 release.   This means that it will be available as a part of the core Nexus OSS offering.   Once Nexus 1.5.0 is released, please try it out and use the issue tracker for reporting any problems you run into and enhancements you would like to see – we’re especially interested in hearing about repositories that the plugin cannot handle! Questions and discussions may be posted to the Nexus mailing list.

In the next few articles of the “Plexus to Guice” series I will look at the modular design of our replacement Plexus container and show how you can configure a POB (Plain Old Bean) from Guice with a simple code example. In the first article of this series, Jason discussed the need to move to a more widely used and support container, and the reasons why we chose to standardize on Guice. As we migrate more Plexus-based applications (such as Maven) to Guice, we still to maintain backward-compatibility for all of the plugins and extensions which were developed using Plexus. In this post, I start to discuss the scope and initial efforts to create something we’re calling the Guice/Plexus “shim”. It is a library, a “container” that was developed to allow existing Plexus components to use Guice under the hood without any modification.

Scope, Architecture, and Conventions

Our goal is to create a swap-in replacement for Plexus built on top of Guice. Ideally this should be done without changing the core Guice code, but if this is not possible then any fixes or new functionality should be written up and reported on the Guice issues page. While there is no guarantee that these changes will make it into an official Guice release, improvements that benefit a wider audience should have a better chance of making it into Guice.

Sonatype currently maintains a patched build of Guice trunk with the following major patches:

• Provide access to Guice’s own internal TypeConverters
• BytecodeGen and related AOP / bridge classloader fixes

This build also contains some experimental changes which have not yet been written up because they are still being tested:

• ability to turn off validation error about using @Singleton on an interface instead of an implementation class
• ability to turn off creation of parent JIT bindings when using child injectors (simplified version of this issue)

Guice/Plexus Integration Module Architecture

The solution is separated into re-usable, pluggable modules that together provide a replacement for the existing Plexus container. There is also an artifact that combines these modules into a single JAR, as this would make it easier to swap between the old and new container. Each module has a specific responsibility and any dependencies between modules is kept at a minimum. The following is a list of the components or modules that comprise the Guice/Plexus integration project.

guice-bean-inject

Extends Guice to support customized injection of named properties (fields and setter methods).

guice-bean-reflect

Provides utility methods and support code for reflection, bean properties, and resource scanning.

guice-plexus-metadata

Shared metadata interfaces, runtime implementations of Plexus annotations, and collection adapters.

guice-plexus-scanners

Annotation and XML scanners that provide metadata about components, requirements, and configuration.

guice-plexus-converters

Standard Plexus type conversion rules that can create instances from simple strings and XML markup.

guice-plexus-locators

Guice based registry that can locate components of a certain type, optionally ordered by name hints.

guice-plexus-bindings

Guice module that uses: scanners to find and bind Plexus component beans, converters to turn configurations into instances, and locators to find components based on requirements. This component also provides a simple lifecycle management API.

guice-plexus-shim

Creates an injector with Plexus bean support, adds Plexus lifecycles, and provides the container API.

A Brief introduction to Guice and JSR330

Guice is a Dependency Injection framework that injects constructors, methods, and fields annotated with @Inject. Guice recognizes both the JSR 330 and the original Guice form of this annotation.

Every injection point (constructor, method, or field) has a number of dependencies, each one represented by a key: the type to be injected plus an optional qualifier annotation that lets you choose between different implementations of the same type. For example:

public class Car {
   // Injectable constructor
   @Inject public Car(Engine engine) { ... }

   // Injectable field
   @Inject @Named("Corinthian Leather") private Seat seat;

   // Injectable package-private method
   @Inject void install(Windshield windshield, Trunk trunk) { ... }
}

Has the following injection points and dependency keys:

Constructor      ---> Key[ Engine ]
Field "seat"     ---> Key[ Seat, @Named( "Corinthian Leather" ) ]
Method "install" ---> Key[ Windshield ], Key[ Trunk ]

The Guice injector maintains a set of bindings that map dependency keys to providers that supply instances of the key type. These providers may use different strategies to supply instances: per-lookup, singleton, per-conversation, even your own custom strategies.

When you configure Guice you are registering bindings from one key to another, or between keys and providers:

// Key[ Seat ] ---> Key[ FoamSeatImpl ]
bind( Seat.class ).to( FoamSeatImpl.class );

// Key[ Seat, @Named( "Corinthian Leather" ) ] ---> Key[ LeatherSeatImpl ]
bind( Seat.class ).annotatedWith( Names.named( "Corinthian Leather" ) ).to( LeatherSeatImpl.class );

// Key[ Engine ] ---> Key[ V8EngineImpl ]
bind( Engine.class ).to( V8EngineImpl.class );

// Key[ V8EngineImpl ] ---> Provider[ V8EngineImpl, "singleton" ]
bind( V8EngineImpl.class ).in( Singleton.class );

// Key[ Windshield ] ---> Provider[ Windshield, "custom" ]
bind( Windshield.class ).toProvider( WindshieldProvider.class );

// Key[ Trunk ] ---> Provider[ TrunkImpl, "constant" ]
bind( Trunk.class ).toInstance( new TrunkImpl() );

The injector can also create certain types of bindings on-demand when no such explicit binding already exists, such as:

// Key[ FoamSeatImpl ] ---> Provider[ FoamSeatImpl , "per-lookup" ]
// Key[ LeatherSeatImpl] ---> Provider[ LeatherSeatImpl, "per-lookup" ]

The Key[...] and Provider[...] markup is pseudo-code

So far so good, but what if you have classes that don’t mark dependencies with @Inject? What if they’re identified in XML or marked with custom annotations like @Requirement or @Configuration?

TypeListeners, MembersInjectors, and InjectionListeners

Since 2.0 Guice has provided a way to supplement the core injection process with your own custom injections. Here’s what you need to do:

1. Register your custom TypeListener, using a Matcher to filter the specific types you are interested in, or Matchers.any() if you want to process all types
2. Guice will call your TypeListener once for each type that matches your chosen matcher, passing you a TypeEncounter
3. You can then analyze the type to be injected, prepare any custom injection data, and use the TypeEncounter to register aMembersInjector or InjectionListener for this type. Because the TypeListener is called per-type, and not per-instance, you should try to do as much preparation work here as possible to avoid spending too much time in the MembersInjector or InjectionListener
4. Guice will call your MembersInjector once for each instance it injects, after it has performed the core injection. You can then use the data prepared by your TypeListener to perform any custom injection
5. Finally Guice will call your InjectionListener once for each instance it injects, after all injections are complete. This is where you can hook in management code, such as start and stop life-cycle support

You’ll notice that Guice does not dictate how each type should be scanned or prepared for custom injection. While Guice does provide utility methods that can tell you which class members are annotated with @Inject, there’s no general-purpose mechanism to scan class members looking for custom annotations. On the one hand this is good, because it avoids bloating the core JAR with code you might not need. But on the other hand each custom injection client could end up implementing similar scanning code again and again. The recommended approach is to put optional code like this in an extension library that people can use if they need to, rather than keep folding it into the core.

We’re going to use custom injection to support Plexus components whose dependencies may be annotated or configured in XML. Plexus components are similar to Java beans in that they can have fields or setter methods, so rather than write a custom injector that’s closely tied to Plexus let’s see if we can develop an extension library for “beans” in general. That way we can build support for Plexus on top of it, and allow people to re-use it for other bean-style injections.

When we started the Maven project, dependency injection was still developing. Spring was just starting out and the Avalon project at Apache was really the only IoC framework around. While the concept seems second-nature by 2010, in 2002, it wasn’t a primary focus of the initial efforts of the Maven community but it was something I felt had to be in place for the development of Maven 2. We knew we needed some sort of component framework, some standard mechanism to instantiate plugins and configure them based on a set of configuration points, and, at the time, Plexus filled the gap. Plexus was exactly what we needed because it evolved with the requirements of Maven, and I think that Plexus served us well for the past few years but it’s time to let go. I never felt compelled to switch until Guice 2.0.   Guice has the capabilities and adaptability we require in Maven.

For all new development, we’ve decided to focus on Guice and build a compatibility layer for existing components. In this post, I’m going to discuss the various factors that went into the decision to move to Guice. All of Sonatype’s product are currently developed using Guice and the Guice/Plexus integration libraries that Stuart will describe in the articles that will follow over the next few weeks, and future work on Maven 3 will be based on Guice.

Why Guice?

We ultimately went with Guice because it provided a system that could be configured and customized at runtime. It was very close to the model that Plexus was using, and we felt that it would be easy for us to build a compatibility layer between the two. The primary motiviation in this decision was our ability to write that compatibility layer atop whatever framework we selected that would allow for backward-compatibility. You see, it isn’t good enough in a community this large to just move to a new framework and expect everyone to just scramble to rewrite Maven plugins. We had to find a way to support existing plugins, and existing extensions. We had to find a way to work with all of the existing code that was coded to Plexus and adapt that to a new engine.

Guice is highly adaptable. With Guice we don’t need to configure all of our components ahead of time, we can instantiate them as needed and modify the “context” with a Guice/Plexus integration layer which Stuart will describe in the following articles. The answer to “why Guice?” is explained in the code that was required to write this compatibility layer. The only way we found to make this work was by using Guice.     Other reasons included type safety, easy-to-read error messages, and OSGi support using peaberry.    All of our development uses the JSR330 standard @Inject anotations.   We’re using JSR330 instead of Guice-specific annotations to make sure that our work is more standard and portable going forward.

Focusing the Community

Aside from the technical reasons to move to Guice, there are reasons that involve the community. If our audacious goal is to provide world-class build and development infrastructure support, we need to remove unnecessary distractions from our environment. We just were not focused on Plexus, and issues would come up in Plexus that needed to be supported which distracted from the core effort. We’re not just using Guice. Because we are starting to rely on it, we appreciate the need to work closely with a project like Guice and contribute back to that community.  Stuart is a committer, and we wanted to collaborate with others and use a framework used widely by others.

Maven’s goal was never to create a dependency injection framework, it was always focused on builds and the infrastructure that supports development. Not long ago, we were contemplating what it would take to improve Plexus, we looked at the effort required to document and support Plexus going forward, and it just didn’t make any sense for us to continue to apply precious time and effort to a problem that had already been solved by several others. It makes sense to focus the community, and moving to Guice will allow us to devote more of our own resources to supporting the central projects and products.

Making it Easier to Extend

When your project or production uses a standard tool, you increase the audience that can customize it. If the goal of Maven is to create a solid foundation of infrastructure for others to build upon, it only makes sense to adopt something more standard. Maven and products like Nexus should be judged by the number and variety of plugins that have been developed for them, and this is something that attract most new users to Maven (the abundance and variety of Maven plugins). Anything we can do to make it easier to extend these systems is the right thing to do for the “ecosystem” I described last week.

If you wanted to write a plugin for the initial version of Nexus two years ago, you would have had to know a lot about Plexus. There was nothing particularly wrong with Plexus, it had a well-defined interface and it served its purpose, but there wasn’t very much documentation, and requiring some knowledge of Plexus for plugin developers was reducing the size of potential developers. In the past year, we’ve made a course correction, and you can write a Nexus plugin without having to learn any dependency injection framework. What has made this transition possible is the flexibility of Guice.

Summary

Stuart’s going to dive into the technical details in the next five parts of this series. If you are a developer interested in the implementation of Plexus and Guice, you’ll find these posts to be a good starting point for learning about we’ve implemented this compatibility layer.

Les Hazlewood has an objective summary of why he eventually came around to deciding that Maven is a better overall solution then Ant + Ivy. This is an evolution in thought process that we, Sonatype, often see in enterprises and Les has two blog entries that illustrate this evolution perfectly.

Maven 2 vs Ant+Ivy: Our selection process: This entry gives Les’ original perspective on Maven and the process by which he originally decided to choose Ant + Ivy.

Maven 2 vs Ant+Ivy: Revisited: This entry gives Les’ new perspective and why his enterprise team, and the Apache Shiro project, have chosen Maven.

I now firmly believe that Maven 2 is a better build and project management tool than Ant+Ivy. I was wrong.

Yep, I said it. I’m man enough to admit when I’ve made mistakes and that I’ve learned from my experiences. And this is coming from the guy that wrote a (still popular) OnJava article for Ant in the enterprise.

Overall, life with Maven is good. I’m glad that I was able to swallow my pride, really give it a chance, and in turn reap the benefits. I haven’t used Ant in over a year since switching, nor have I ever felt the need to go back.

We hope this perspective helps potential enterprises save time when looking for a build and release infrastructure.

Last month there was an article on TechRepublic entitled “10 questions to ask when selecting open source products for your enterprise”.   As both a consumer and producer of open source enteprise software, I thought that this list of questions captures the areas that people should be thinking about when they are selecting a technology.   Open source technology selection is about much more than just feature comparison.   When you are selecting an open source technology, you have to think about licensing issues, the scope of the supporting community, and open source governance models.   Since we’ve been talking a lot about Nexus, I wanted to summarize our efforts by answering these questions for potential users.  If you’re trying to decide what repository manager to use in your organization I hope that the answers to these questions help you make an informed decision.

1. Are the open source license terms compatible with my business requirements?

There are many possible things to consider here but, I believe, the primary points to consider for an OSS application are:

• Can I extend as necessary?  Is there anything about the license that is going to prevent me from extending the product or fixing a problem?
• Is there going to be someone around to support the product long-term?  Is the license going to provide a way for the organization backing the project to survive well into the future?

We thought for a long while before selecting the GNU Public License (GPL) for Nexus and we made it clear right from the start why we chose the GPL. We knew that we would invest heavily in Nexus.  Even though the people involved with Sonatype are traditionally users of Apache style licenses, we didn’t know how our business would evolve and we wanted to choose a license that would offer adequate protection for that investment. We were honest and upfront about it. We chose a more restrictive license first this allows us to adapt and use a less restrictive license in the future if we think it is appropriate for the community.

If you are considering software for an enterprise then you want there to be a supporting company, or companies, and the business model of the supporting company is important because you want them to be around for a while.   GPL gives us some way to protect our investment, and it allows our end-users to extend and customize an open product.

2. What is the strength of the community?

The people working at Sonatype are the key people in the Maven, Nexus, and m2eclipse projects.   Community work is an essential part of the everyday work of each of our developers.    While we focus on creating great software, many of the libraries and tools we use are produced within the Maven community – an ecosystem that encompasses several commercial participants, approximately 20 core developers, and millions of users.   Nexus Professional helps to maintain the Central Maven repository which is used by millions of developers world-wide.

One of the core goals of the Nexus project is to strengthen the technical infrastructure of the community it supports.    This technical symbiosis is evident in the work that Brian Fox, our VP of Engineering, has been doing to help manage important OSS repositories. We are currently working with organizations and companies including Alfresco, Apache, Atlassian, Codehaus, ExoPlatform, Glassfish, Open QA, Scala-Tools, and JBoss to support the creation of quality artifact repositories that feed into the Central Maven repository.  This Central Maven repository is the central collaboration point for the entire world of Java developers.  In addition to working with the main feeder repositories, there is also an instance of Nexus available to any open source project that wishes to take advantage of the services available at http://oss.sonatype.org. We already have a large number of projects using this service and it’s growing by the day.

Nexus is also at the center of an effort to unify disparate languages and technologies on a single repository platform.   Our recent efforts to support RubyGems, OBR, and P2 repositories are attempts to unify disparate communities into a single community supported by a platform which favors interoperability.

3. How well is the product adopted by users?

Going back to the previous answer, the adoption of Nexus is something that is evident in the number of OSS “forges” that have selected Nexus. At virtually every important OSS forge there is now an instance of Nexus running, and Nexus has been integrated into the software release process. Nexus is also used to help Maven Central as well which is the largest public artifact repository in the world. Nexus has rapidly become the de facto standard for artifact repository management.

Another data point that reflects adoption by users is the number of times a user will answer a support question on a public list.   On the Nexus IRC channel and Nexus user mailing list, we’ve noticed a trend over the past few months where non-Sonatype employees are starting to answer user questions about Nexus without any involvement from the Nexus development team.   This community involvement in the support process is a sign that Nexus users are not just installing the product and going away, they are starting to become productive and active members of the community that surrounds Nexus.

4. Can I get a warranty or commercial support if I need it?

Of course. Sonatype provides professional support for our commercial Nexus offering.   When you purchase Nexus Professional you get one year of support which includes commitments to turn-around time for solving critical issues.   Nexus Professional users are also given dedicated channels that they can use to communicate directly with the Nexus team.  Sonatype currently offers enterprise-level support to some of the largest companies in the world, and this support is built into the product.

For Nexus Open Source we are very responsive to users on our mailing list, and we are constantly available on an IRC channel to answer any questions from users who have any questions for us.

5. What quality assurance processes exist?

Sonatype is fanatical about quality.   We are so committed to quality that we’ll delay our software releases indefinitely if they don’t meet our strict quality assurance procedures.     We’d rather release nothing than release software before it is ready because we know how frustrating it is to use software that feels like it is half completed.   If you don’t take our word for it, take a look at our issue tracker’s release notes for the 1.4.0 release to get a feel for the level of detail you can expect from us with a release.  Nexus has, without a doubt, the best QA process for any of the repository manager that exists. You only need to look at our unit tests, integration tests, and full manual regression test suite to get an idea of how stringent we are.

While our internal development process revolves around quality, sometimes the only way to really shake out the bugs is to run your product in a production environment.   Sonatype has the great benefit of running Nexus on the most active OSS forges in the world.    We run Nexus instances for open source projects that serve gigabytes of artifact data every day, and we often find problems with Nexus long before our users even had a chance to notice.     Our product also ships with automatic error detection and error submission mechanisms that will communicate problems to our support staff as they happen in the field.   We are proactive about finding problems before our users and customers.

6. How good is the documentation?

Sonatype views documentation as a key differentiator.    “Repository Management with Nexus” is a free book, available on the web, as a PDF download, or as a printed book from Lulu.com.   This 325-page book contains 19 chapters and five appendices that detail every facet of Nexus Open Source and Nexus Professional.    Complete with an introduction to the concepts and motivation behind repository managers, this book is a comprehensive reference.  The Nexus book is available from: http://www.sonatype.com/books/nexus-book/reference/

7. How easily can the system be customized to my exact requirements?

Nexus follows the Open Core principle where we have a solid kernel that is extended by plug-ins. We have many OSS and commercial users who have extended Nexus and we are trying to make that even easier to do. Damian Bradicich, one of our core developers, wrote a blog recently about our efforts to make developing Nexus plugins simple.  We’re focusing on ways to make it even easier to start a Nexus plug-in project, and develop and debug these plugins inside Eclipse.

Nexus, as a platform, is about as extensible as it gets.   We’ve designed the system to be agnostic about the types of artifacts is manages, and you could extend it to manage, index, and distribute any kind of binary artifact.   It really wouldn’t even need to be limited to software.  We’ve considered developing some proof of concept demonstrations to show people how Nexus could be used to store, index, and distribute audio and video content using the extensible RDF metadata capabilities to store metadata and the customizable UI to present multimedia content.   The point isn’t that you would ever need to do this, it is to prove that Nexus could be customized to satisfy any requirements you could throw at it.

8. How is this project governed and how easily can I influence the road map?

The Sonatype development team includes a number of key participants in the Maven community.  We’re very familiar with the importance of open source governance models because we’re actively involved in one of the most active and open communities in open source.   Even though Nexus is a Sonatype project, we appreciate the need to adhere to the core values of other successful open source project.   First and foremost, the project is run as a meritocracy, good ideas trump status and hierarchy.   Second, we value transparency for the Nexus Open Source project, and we understand the need to adhere to a common set of policies and procedures to make it easier for external contributors to contribute and participate.

The Nexus project currently includes four external developers who have contributed enough to the project to merit commit rights to the source repository.   If you are motivated enough to volunteer and contribute your time to this open source project, we welcome your contribution.

9. Will the product scale to my enterprise’s requirements?

If you are talking about scalability in terms of number of users or projects using Nexus, there is no greater proof than the fact that Nexus is used to manage two of the largest feeder repositories for the Central Maven repository.    Nexus is used to manage the Apache release and snapshot repositories and the Codehaus repositories.   Both of these projects approximate the largest corporate environments in the world with thousands of developers distributed across the globe, enterprise LDAP servers, and a high volume of requests from clients requesting artifacts.

Nexus was designed, from the beginning, to meet the requirements of global-scale open source development.

10. Are there regular security patches?

Sonatype tends to make a point release of Nexus once every month.   We’re currently about to cut the 1.5 release of Nexus, and, with every release, we fix a number of bugs that have been uncovered by our testing procedures.    Because we run some of the highest profile repositories on the internet, we are constantly patching Nexus to meet security issues that most of our customers would never need to worry about.   We’ve dealt with distributed denial of service attacks and other security issues as part of maintaining the central maven repository.  Nexus is battle tested and secure.