I’m happy to announce that Pascal Rapicault, lead of the Equinox p2 team, is going to be joining Sonatype. As lead of p2, Pascal’s work has helped define the way that components are designed, developed, and deployed within the Eclipse framework. I’m confident that his work is going to be an essential part of what allows Sonatype to create some of the Next Generation development infrastructure I’ve been describing over the past few weeks.
I’m very excited about the opportunity to join Sonatype because they have an exciting portfolio of products and a commitment to open source (Maven, m2eclipse, …). Therefore I will continue to be heavily involved in the Eclipse community and provide leadership for the p2 project. I look forward to being a part of the Eclipse team from a new perspective and have no doubt that I will run into other members of the Eclipse team in the future.
We’re happy to have him on board, and you can look forward to see his work and his writing on this blog in the months to come.
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 →
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 →
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: 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.
Since the center of the Maven community lies within communities that value the Apache license, I feel compelled to add some explanation for people who want to know more about what went into this decision. In this post, I’m going to walk you through what went into this decision and talk about some of the general ground rules we’re following when it comes to making license decisions.
Why we chose the GPL license for Nexus
Normally we would have used a BSD/MIT/Apache license for software that we develop. This is what we’re used to, with most of our developers having been active in the Apache community for years, we’re all very familiar with the philosophy behind this license. When we announced that Nexus was going to be released under a GPL license, some of our colleagues wanted to know how a group of Apache participants decided to use the GNU Public License?
Continue reading →