Wondering what’s new in Nexus? Just ask the experts.

We’re hosting another Nexus Office Hours this Friday, on Google+ Hangout On Air. Our Nexus experts Brian Fox, Manfred Moser and Rich Seddon will demo the latest in Nexus and dedicate most of the hour to Q&A time with you!

How to join: No registration required, just RSVP on Google+, and the event will appear in your calendar. You can join through your calendar invite or by returning to the event page at the start of the hangout. Be sure to bring your Nexus questions with you. If you can’t make it — be sure to leave your questions on the event page in the comments section and we’ll be sure to answer them during the session. That way you can tune into the recording later, and get your answers!

*Interested in joining our panel that day in the video conference? Sign up for one of the spots on our panel, by leaving us a comment on the event page and we’ll invite you in before we go live. Space is limited, so be sure to sign up early!

Please feel free to pass along this invite to your friends and colleagues.

RSVP

We’re pleased to announce that Sonatype will be hosting Nexus Office Hours each month starting in March! Our Nexus experts Brian Fox, Manfred Moser and Rich Seddon will demo the latest Nexus tips & tricks and will take real-time questions from you!

When: Friday, March 22, 2013 – 1:00-2:00PM EDT (GMT-0400)

Where: In a Google+ Hangout On Air! Once we begin, our hangout will broadcast live to the Nexus Office Hours event page on Google+, as well as our Sonatype YouTube channel.

How: Be sure to RSVP ‘Yes’ on the Nexus Office Hours event page, and this event will be automatically saved to your Gmail calendar and you will receive a reminder just before we start the hangout. Not on Google+? No worries, you can still view the broadcast on the event page or the Sonatype YouTube channel when the hangout begins.

We will be taking real-time questions submitted on the Nexus Office Hours event page, Twitter (please use hashtag #nexusofficehours) and on our YouTube page in the comments section of the broadcast.

**If you’d like to join our panel that day in the hangout, please leave us a comment on this page and the first 6 people will be invited in as the session starts. This event will be recorded and saved to Google+ as well as our YouTube channel.

RSVP Now

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.

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.

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.

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!

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.

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.

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.