Author Archives: Jason van Zyl

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!

Apache Maven 3.0 has landed!


October 8, 2010 By Jason van Zyl

Apache Maven 3.0 has landed, but it’s really just the beginning. The work that Sonatype has done to bring Maven 3.0 to fruition is substantial. It’s been hard, it’s taken a lot of Sonatype’s time and resources, but we’re glad we did the work and we see this as a new beginning for Maven. We will, of course, keep working on Maven but with the release of Maven 3.0 Sonatype will, at least for a little while, turn an eye to Maven’s Eclipse-focused cousins, the Maven Shell, Polyglot Maven, and Hudson.

We have work to do on Tycho to get it fully setup for the parallel IP process at Eclipse, we will soon start a very intensive set of iterations to bring the M2Eclipse core to a 1.0 state, and we have committed within Sonatype to move M2Eclipse to the Eclipse Foundation. The M2Eclipse project at Eclipse has been in suspended animation for a while but we plan to work toward getting M2Eclipse into the release train and have Indigo be the first Eclipse distribution to ship with Maven capabilities. Tycho and M2Eclipse will also be a lot of work, but I think Sonatype has demonstrated that we’re committed to making these projects work and can deliver as we’ve shown with Maven 3.0.

There will be a release fairly soon of the Maven Shell, I will be starting a new phase of work on Polyglot Maven, and I’ll also be talking about concretely what Sonatype plans to do around Hudson — and what we’ve already done. Once we get a few more of the projects we’re working on to a healthy state we will begin the dialog with the community about what features users are looking for in future versions of Maven and related tools.

The Maven community owes a special thanks to Benjamin Bentmann, who has worked consistently and persistently for a long time on Maven 3.0. He has been amazingly responsive in applying fixes for reported issues, and has set the bar very high for the quality of a open source project. We have an enormous number of integration tests and without a doubt, Benjamin really has made this the best version of Maven we’ve ever had. I’d also like to thank Igor Fedorenko who is responsible for Tycho, along with all the changes he made to Maven core to allow its dynamic adaptation, as well as putting in place the performance framework for Maven 3.0. And Maven users can also thank Oliver Lamy for making sure the Maven Site Plugin is compatible with Maven 3.0.

You can download Maven 3.0 now!

http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0-bin.zip

http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0-bin.tar.gz

Enjoy!

Please try Maven 3.0 RC1!


September 16, 2010 By Jason van Zyl

We are very close to Maven 3.0! In preparation for the release we are entering the RC phase Sonatype is seeking the Maven user community’s help to discover regressions since Maven 2.x so that we can make the necessary provisions to correct any problems and push Maven 3.0 final out on schedule.

We know as the RCs are released more people will be trying Maven 3.x and feedback is critical. We obviously cannot fix your problem if you do not report the problem. Sonatype has two full-time people working on fielding the found issues so this is your chance to make sure Maven 3.0 final works for your projects. Sonatype has made a great deal of effort putting in place unit tests, integration tests, and performance tests for the core and the core plugins, so we’re ready for the feedback and will correct anything we find quickly.

Anyone interested in taking a preview of the upcoming release for a test drive can get source and binary bundles from this URL:

https://repository.apache.org/content/repositories/maven-030/org/apache/maven/apache-maven/3.0-RC1/

Note that this is a staged release and we will keep re-staging while we find serious regressions, but we want to get users into this cycle of testing the RCs as soon as possible. Once we get past anything nasty we will release the final RC1.

Before reporting any issues found during testing, please be sure to have a close look at the compatibility notes for Maven 3.x:

https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes

If you encounter unexpected build issues, please fill a report in JIRA that provides sufficient information to reproduce and analyze the issue:

http://jira.codehaus.org/browse/MNG

The fixes contained in this release candidate since the 3.0-beta-3 release can also be seen in JIRA:

http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=PRIR5ueW-i&version=13142&styleName=Text&projectId=10500&Create=Create

It’s still possible to make our intended Maven 3.0 final release on October 1st, but we need your help!

Thanks!

Aether questions answered for JAX


August 9, 2010 By Jason van Zyl

JAX asked me some questions about Aether so I’m providing the the English version of the answers here for the community. The German version should show up on the JAX site shortly.

Can you give us an introduction to Aether?

Aether is a library for interacting with artifact repositories. This involves the specification of local repository formats, remote repository formats, workspaces, transports, and artifact resolution. People are generally familiar with repositories whether they be local or remote. Workspaces are additional sources where artifacts can be resolved from. Workspaces can be used in IDEs to provide resolution of projects you are working on, in shells like the Maven Shell or Roo, or any other long-lived process where a developer needs to resolve against in-development projects. I think people are familiar with various transports but HTTP is by far the dominant transport used with artifact repositories, but Aether lets you define additional ones if you need to. Along with all the rules to resolve artifacts taking into consideration any transformations, relocations, and conflict resolution strategies you might need to employ. We also plan to allow Aether to define version schemes, but the first work was just started on this by Alin Dreghiciu.

It is very important to note that Aether has no dependencies on Maven. When I said Aether is a library for interacting with artifact repositories, I didn’t mean Maven artifact repositories. Aether is a general purpose library for interacting with artifact repositories. If you wanted to specify your dependency metadata in a properties files Aether will let you do that. If you want to store your artifacts in a database Aether will let you do that. But, of course, we needed Aether to work for Maven so we created an implementation of what we call an ArtifactDescriptorReader to process Maven POMs. That implementation lives in the Maven codebase and that’s how we make Aether work for Maven.

Continue reading →