Category Archives: Maven

Maven IDE: The year of Maven & Eclipse


January 10, 2011 By Jason van Zyl

There are many things we would like to see accomplished in the Apache Maven ecosystem in 2011 but one of the most important, we feel, is the sound integration of Maven with Eclipse. A great deal of effort was spent bringing Maven 3.x up to the level where it can be leveraged for an effective integration with Eclipse. With Maven 3.0 released in 2010 we are in a position to focus on the Eclipse side of the equation. For those you who watch the M2Eclipse JIRA you can see a great deal of activity and that’s because Sonatype’s M2Eclipse team is doing for M2Eclipse what Sonatype’s Maven team did for Maven 3.0. Sonatype is working on the internal architecture of M2Eclipse, adding tests, and preparing the path forward which means the integration of Maven with the rest of the Eclipse ecosystem.

Sonatype is investing heavily to ensure the baseline M2Eclipse 1.0 is of high quality, stable, and maintainable. With the help of the amazing IP team at the Eclipse Foundation M2Eclipse has passed its initial IP review, has entered the parallel IP process and is slated to be released as part of the 2011 Indigo release of Eclipse. To be certain, this will be a great milestone for the Maven and Eclipse ecosystems: users have been asking for years to have good Maven integration included in the standard Eclipse distributions and this will be the year they get it. Indigo will ship this year on June 22nd, but in the meantime Sonatype will be working on and soon releasing Maven IDE!

MavenIDE.png

What is Maven IDE exactly? Maven IDE is a Maven-focused distribution of Eclipse that will consist of a base Eclipse distribution, M2Eclipse and a series of Maven-focused integrations where there is strong support within the Maven and Eclipse ecosystems. What are some of the things we are looking at potentially integrating?

Frameworks and languages

JSR-330 & Guice integration: JSR-330 & Guice are now critical to the Maven ecosystem and very important to Sonatype as a technology. The JSR-330 implementation provided by Guice provides core functionality for Maven 3.x, Nexus, M2Eclipse, and Sonatype’s Maven 3.x integration for Hudson. We will create tooling for JSR-330 to help with our own work, general integration work for development infrastructures, and anyone using JSR-330.

Webapp development tooling: Webapp development is the most requested form of integration and we are still evaluating what’s available in WTP versus making something that is simpler and integrates more tightly with Maven. For those that don’t know, the WTP integration for M2Eclipse is not part of the codebase that moved to Eclipse. Sonatype will be working with the community on the M2Eclipse/WTP integration and will help distribute it from Sonatype, but we are also looking at alternatives to WTP.

Tycho integration: We already have support for Tycho inside Eclipse that allows Tycho projects to interoperate with PDE at a rudimentary level, but we would like to improve this integration and bring support for Tycho-based projects into the Eclipse IDE.

Maven Shell integration: This is where the Maven command line will intersect with the IDE. We see in the future being JSR-330 component based so we can leverage them from the Maven Shell and Maven IDE, and these components will participate in long-lived workflows that aid in the development of applications. We plan to use Drools Flow for the workflow implementation and the Eclipse tooling that exists for Drools Flow. The workflows will be accessible and usable from the Maven Shell as well as from within Maven IDE.

Polyglot Maven integration: For some of the selected grammars and dialects of Polyglot Maven we will provide support in Maven IDE. The folks at Itemis have been a great in helping us understand how Xtext can play a critical role in this regard. If a grammar can be represented in a form that Xtext understands then much of the plumbing for powerful editors can be created automatically using the Xtext framework. There are currently some integration issues between standard Maven and OSGi that need to be resolved but Xtext is an incredibly powerful language workbench. The Itemis guys have really done some incredible work.

Android development tooling: Android is becoming very popular and has a strong Maven contingent. There are sophisticated Maven-based tools for developing Android apps that have been created by Android community: the maven-android-plugin by Hugo Josefson from Jayway, the Eclipse integration exists as part of what Google provides, and Ricardo Gladwell has created the bridge between Maven and Eclipse with his Android M2Eclipse integration.

Scala IDE: Miles Sabin is creating great Eclipse integration for Scala with his Scala IDE project and David Bernard is bridging that work into Maven m2eclipse-scala. We are seeing a lot of demand for Scala integration with Maven.

GWT integration: GWT has rapidly become one of the standard webapp toolkits for Java and we’ve seen a lot of demand for better integration with M2Eclipse. Within the realm of development infrastructure GWT is very popular. Sonar uses GWT, Gerrit uses GWT, XWiki uses GWT, and Sonatype has chosen GWT as the basis of the UI for our Maven 3.x integration in Hudson. GWT will continue to gain momentum so it’s very likely we will have more sophisticated integration with M2Eclipse sooner rather then later.

Development infrastructure

Sonar integration: Sonar is becoming the de facto standard reporting and quality system for Java projects. Sonar is very Maven-centric and SonarSource has provided Eclipse integration that can easily be integrated with Maven IDE.

Hudson integration: Hudson is the de facto standard continuous integration server for Java projects. Sonatype is currently working on finishing our Maven 3.x integration and it will be integrated within Maven IDE.

Wiki editing & site publishing: Sonatype has a wiki page editing and publishing framework called Idiom — that is based on the WikiModel project — that we will be open sourcing, and hopefully merging with the tools that exist in the WikiText project at Eclipse. Ultimately we would like to see WikiModel merged with WikiText and then work together within the community to make great editing tools. If WikiModel could be wed with Xtext it would be amazing.

SVN integration: Obviously important and we initially removed the SVN support to clean up and focus on the core. We’re layering it back in as resources permit. It’s not going anywhere and there are actually two options now. Sonatype supports the Subversive integration which is the official SVN integration at Eclipse, but the community has contributed the Subclipse support. So both variants will be available and Maven IDE will ship with the Java-based SVNKit connector.

Git integration: Git is sweeping over the development community and has taken off like wildfire. At Sonatype we use Git for the vast majority of our projects so great Git integration with Eclilpse and Maven is vital.

Maven Central statistics and metadata: Many OSS projects have been thrilled with the statistics we’ve provided them and we’ll be working in the future to provide more value from the information in Maven Central and deliver it into Maven IDE. Maven Central is an unparalleled source of interesting and useful information for developers and we want to make all that information more accessible.

So you can see that the number of paths we can potentially take are limitless. What will really help us limit our choices are the partners we find who are as committed as we are to the Maven and Eclipse ecosystems. We’re not interested in individuals, groups, or organizations that are hedging their bets with Maven and Eclipse. We are looking for individuals, groups, and organizations who are committed to the Eclipse Platform and Maven as the basis of their development infrastructures.

Things we’ll be looking for in integration partners, are: Tycho build, good test infrastructure, and a composite p2 repository for integration. Maven IDE will first be available in an OSS community edition and will be followed by future commercial versions. We are excited about building out a polished, Maven-focused distribution of Eclipse and we’re really looking for feedback from the community about what integrations to pursue first. So please let us know!

Apache and Apache Maven are trademarks of the Apache Software Foundation. Maven Central is a service mark of Sonatype, Inc. Nexus, Maven IDE, Maven Shell, and Polyglot Maven are trademarks of Sonatype, Inc. Maven Central, Maven IDE, Maven Shell, and Polyglot Maven are intended to complement Apache Maven and should not be confused with Apache Maven.

Guice 3.0 RC2 is in Maven Central!


By Jason van Zyl

While it may seem a small thing, getting Guice 3.0 RC2 into Maven Central is actually quite a big deal. At this point Sonatype has been working well over a year to make this happen as it wasn’t just simply a matter of making some JARs and foisting them into Maven Central. Guice 3.x is now an integral part of Maven 3.x, Nexus, M2Eclipse and Sonatype’s Maven integration for Hudson so we care a great deal about the Guice ecosystem.

We started by providing patches to Guice for Maven 3.x and OSGi integration, working with the core committers to get our patches reviewed and vetted. At this point we only have a couple of patches (one for a deadlock fix in Nexus, and native injection of SLF4J loggers) that have not been integrated into Guice proper. Stuart McCulloch from Sonatype worked with Bob Lee, Jesse Wilson, Dhanji R. Prasanna and, now primarily, Sam Berlin from the Guice team to work in the patches in an acceptable way. We could have just forked Guice, and that probably would have been easier, but ultimately you can’t just go forking everything whenever you need a fix because eventually this become untenable. The surface area to support becomes unmanageable so spending the time and resources upfront pays for itself several times over fairly soon. The Guice guys are all perfectly reasonable: they want high quality, well thought out contributions and aren’t willing to take patches that work for limited use cases at the cost of the rest of the community. We appreciate that perspective and have no problems working within those confines.

While the patches were being integrated we also started looking at a Maven build for Guice. Sonatype has extensions for Guice, called Sisu, that allows the adaptation of any dependency injection system to Guice and so we initially needed a Maven-based way to build Guice and integrate our extensions so we could deploy them to a Maven repository for testing. Over time we started to Mavenize more of the Guice build and integrated the POMs the Guice user community created. The problem we were faced with was that the core Guice committers use Ant to build and they had no desire to use Maven in their day-to-day work. That was fine with us, we weren’t trying to jam Maven down anyone’s throat so we agreed that if we could make binary equivalent builds that the Maven build could be used to produce the artifacts that would be pushed to Maven Central.

This took quite a bit of work, review and patience but after making some adjustments and creating a couple new plugins we were able to make the Ant and Maven builds produce the same output. Along the way we made a new version of the Maven JarJar Plugin, which is now being used as part of the Maven-based Guice build, and updated the POMs to work with Sonatype’s Nexus OSS infrastructure so we can automate the release of Guice artifacts into Maven Central.

The final result is that we can now use Maven as part of the Guice release process to produce artifacts that satisfy the requirements of the Guice team and Maven Central. With the release of Guice 3.0 RC2 we have Guice itself along with all the standard Guice extensions available in Maven Central. Many thanks to the folks on the Guice team from Google, we know that Maven is not your first choice for build systems but appreciate you being accommodating and helping us create the process that gets Guice artifacts into Maven Central. Makes for a good day in the Guice community!

Enroll today for Maven 201: Development Infrastructure Design


By hloney

Sonatype Training

You’ve completed Maven 101, learned about the Maven lifecycle, Maven plugins, goals and projects, all about the contents of the Project Object Model (POM) – so what’s next?

For those wanting to dive even deeper into Maven, Sonatype is offering an online training course, Maven 201: Development Infrastructure Design.

Maven 201 covers advanced topics such as:

  • Advanced multimodule project architecture
  • Enforcing standards with the Enforcer plugin
  • Installing and configuring a repository manager
  • Installing and configuring a continuous integration server

At the end of this training course, you will have advanced familiarity with the structure of a Maven POM and a Maven multi-module project.

Next training course:

  • MVN-201
  • January 20 & 21, 2011
  • 11:00 am – 4:00 pm EST (GMT – 05:00)
  • Enroll today

How to Use Aether in Maven Plugins


January 7, 2011 By Bentmann Benjamin

When developing plugins for Maven 3.0 plugin developers that need to perform dependency resolution have a choice: they can continue to use the Maven 2.x API, or they can use the new Maven 3 API which makes use of Aether. In this post, I’m going to walk through some of the API features that are now available to plugin developers in Aether.

If your plugin needs to be compatible with Maven 2.x, take a look at the sources of Maven Dependency Plugin. This example provides a sophisticated example of using the Maven 2.x dependency resolution API. But if legacy Maven support is of no concern to you, read on and see how the Maven 3.x API handles the job.

Continue reading →

What's in Maven 3.0 for users?


December 22, 2010 By Bentmann Benjamin

Asking the Maven issue tracker for all the changes or fixes that contribute to our freshly released Maven 3.0, one ends up with about 420 issues. While this is a rather large number, most of these issues deal with regressions we encountered and fixed during refactoring of the internals. But those issues are uninteresting to users that consider upgrading from Maven 2.x and want to know what’s the delta to 3.0.

The primary source of information for this delta are the compatibility notes and the plugin compatibility matrix.  These documents focus on changes that could negatively affect existing builds due to stricter behavior of Maven 3.0, but we also managed to implement a few general improvements here and there.

Continue reading →