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.
Continue reading →
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. 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 →
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. Continue reading →