While Maven 3 is a dramatic improvement over Maven 2 from the perspective of performance, extensibility, and architecture, most end-users are motivated by plugins. This has been true about Maven from the beginning, while the framework has value, it is the plugins that make the difference. This blog focuses on the changes that are of interest to plugin authors.
Nexus OSS Core has more than 120 REST Resources published. And that number is just increasing with new Nexus Plugins. Not to mention Nexus Pro that comes with even more plugins and more REST resources. Everything you do in Nexus, whether you use the Maven Nexus plugin or the Nexus UI, is interacting with a REST service that is available to you if you want to write your own customizations and scripts. It has been this way since we started the project in 2007. In this post, I’m going to discuss how this came to be, how Nexus was developed with REST in mind from the beginning.
When we started the Nexus project, I called it a “blind” application. A “blind” webapp is one with no UI technology whatsoever built-in. All it publishes is a few static files, and a REST API. All of the UI that you see in Nexus is Javascript. Your browser executes Javascript which, in turn, interacts with a set of services. The only presentation technology on the server side is a trivial Velocity template used to render the initial “shell” of the page. Continue reading
In the first two articles in this series you learned why Sonatype has decided to move our development efforts from Plexus to Guice and you’ve also been introduced to Sonatype’s efforts to create a Guice/Plexus integration library to make the migration from Plexus to Guice seamless. In this post, I’m going to dive into the details of bean injection in Guice, and I’m going to demonstrate how you can use the general-purpose bean injection layer in the Guice/Plexus integation library to intialize a bean. This post is highly technical and is meant for developers interested in the details of our attempts to bridge Plexus and Guice. Continue reading
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. Continue reading
