Last week saw the release of Eclipse Indigo, which is the annual release of Eclipse projects. This year 62 projects were included in the release, including m2eclipse from Sonatype. However, since Indigo’s release there have been some questions as to where users can find m2eclipse.

Sonatype software developer Pascal Rapicault recently answered those questions on his blog, and we’re passing the information on to you.

Helpful links:

As mentioned earlier on the Sonatype blog, we’re taking some of our most popular sessions from EclipseCon 2011, and releasing them to the wider developer community. The second installment from EclipseCon 2011 is m2eclipse: The collaboration of the Maven & Eclipse Platforms.

Software developer Igor Fedorenko details the new features and changes to m2eclipse 1.0, including pom.xml editor enhancements and reworked build lifecycle mapping.

For more videos from the Sonatype team, visit our Resource Center, or go to our YouTube channel.

Today we are releasing m2e 0.12.1. Despite our previous announcement that 0.12.0 would be the last version made available from Sonatype, we have decided to cut this point release to make available new versions of the m2e dependencies.

Most notably, this release includes recently released Maven 3.0.2 embedded runtime and an updated version of Async HTTP Client that resolves all known issues reported against m2e 0.12.0, and thus helps make m2e work better in corporate environments.

As usual this version of m2e is made available from the Eclipse Marketplace and from http://m2eclipse.sonatype.org/sites/m2e/.

Enjoy!

Sonatype is pleased to announce the launch of Sonatype Professional, the only integrated development suite for Maven-centric Java development. Sonatype Professional integrates and enhances a range of popular open source technologies to streamline Java software development and is specifically designed to improve both the speed and quality of your Java builds. Sonatype Professional integrates the m2eclipse, Nexus Professional, and Matrix Professional (Hudson-based continuous integration) and adds unique developer onboarding functionality to get you productive fast.

Sonatype Professional is tightly integrated with the Eclipse development environment to streamline builds, artifact search and reuse, defect detection, and bug fixes. From within Eclipse, users can:

• Visually manage Maven
• Browse and search Nexus repositories
• Submit Hudson continuous integration jobs
• Receive real-time build and continuous integration alerts
• Jump quickly to broken code

To learn more click here.

As previously mentioned we are in the process of moving m2e to the Eclipse Foundation.  Currently we are going over the implications of this move from an end-user perspective and an m2e extension developer’s perspective.

From an end-user perspective this means a wider availability of m2eclipse, but more importantly it means an alignment of m2e with the main Eclipse components and also with the Eclipse releases.  m2e will be participating in the Indigo release train and we have asked for its inclusion in the Java Developer Package.

Eclipse is known for IP cleanliness. Through its very thorough IP review process, the Eclipse Foundation has been known to only make available code with a very clear pedigree. In fact, it is this very process that prevented us from moving our code to Eclipse a couple years ago. We now have addressed all the issues uncovered in this initial attempt.

You may wonder, how does this help me? It does not make m2e run faster, or better? You are right, but it helps where you can’t see.  It helps making someone in your management chain more comfortable with the usage of m2e, but also enables m2e for inclusion into more Eclipse-based products and to some extent favor the creation of m2e extensions.

From an extender perspective, this move means work. In fact, since m2e namespace will now be org.eclipse.m2e instead of org.maven.ide, m2e extension developers will to be forced to change their code to have their extensions work with the new m2e. Despite our commitment to work in Eclipse 3.7 (Indigo), m2e is still targeted to work on Eclipse 3.5, 3.6 and 3.7, which means that you should not have to maintain two branches of your code one for the “old” Sonatype m2e and one for the new Eclipse m2e.

Overall despite the initial hurdle that can result from this sort of move, we are deeply convinced that it is a great opportunity for the m2e community at large.

Sonatype recently announced the availability of m2eclipse 0.12.  This release includes support for Maven 3.0 and many improvements in the HTTP transport code. This should be the last release made available from the Sonatype servers.  But not to worry, we are not stopping the development. In fact, quite conversely, we are ramping up our efforts on the m2eclipse core and moving m2e to the Eclipse foundation.

At this point, the move has not been completed as we are still working with the Eclipse IP team to get all our code and dependencies reviewed. If all goes well, we are hoping to have everything moved to the Eclipse Foundation by mid-December. In the meantime the development is still happening on github but under the new org.eclipse.m2e name-space. We will keep you posted when the code has been completed moved.

I just wanted to let people know what’s been happening with m2e recently and what we’ll be focusing on in the near term. Recently, there has been a lull in the number of releases because we have decided that testing and quality are the priority so we had to take a step back and figure out a plan of action.  The primary outcome is that we feel that the infrastructure for the testing needs to take precedence in order for everything else to fall into place. New feature development has to take a back seat to make sure the current functionality is flawless in execution.   Quality is our primary concern, and this means that all new features have to be backed by a completely automated tests (including automated UI tests). As we have discovered, this is an extraordinarily difficult task to accomplish. Provisioning target platforms, meshing Tycho with Hudson for CI/Releases, and automating UI tests is not simple by any stretch of the imagination.

Nonetheless we’re committed to the task and we’ve hired Rich Seddon to create the testing framework and infrastructure.  Our goal is to reach the standard set by Nexus which has so many integration tests that virtually nothing regresses and we can refactor and add new features without introducing new bugs.  Unfortunately, we know from experience in our training classes and feedback from users that m2eclipse has not reached this level of quality and we are fully addressing this fact by committing ourselves to testing and quality. We probably should have pursued fewer features and more testing, but what’s done is done.  From this point forward, testing is our primary concern. We will be able to add some new features, and do some architectural work to help stabilize m2e for the 1.0 but we’re basically going to be eradicating defects and adding the testing which will facilitate the convergence of m2e with the current Maven trunk and ultimately the Maven 3.0 final release.   In this post, I’ll walk through what we’re doing at a high level and then try to layout a schedule for what’s going to happen in the next few months.

Testing Plan & Test Automation

We are working on getting a complete feature map which will allow us to accurately test the features we purport to provide in m2e. Along with the feature map, we are gathering standard use cases and creating test plans around those. For example, we are trying to walk through the chapter in Maven: The Definitive Guide on m2e and finding that we even have problems there. So, we will be mapping out the features, creating standard projects and standard workflows to test.  Throughout this process, users will have the opportunity to participate. We also want to make it as easy as possible for users to get involved and having a large number of tests can only help us in that area. We’ll be documenting the testing setup and we’ll also be making it easier for people to write tests so they can, in general, participate more effectively.

Documentation

Tim O’Brien who is responsible for the Maven: The Definitive Guide is going to pull the m2e chapter out of the Guide and create a more complete mini-book which will describe with example the features we have mapped out. Right now we have many documents in the Wiki which are hard to find and piece together, so it will be Tim’s task to organize this documentation and add to it so that we can provide a free “book” about m2e.  We’re also expanding our documentation presence to produce more cookbook-style “recipes”, and we’re rethinking the idea of the online book to provide smaller, more targetted guides for people looking to learn quickly.

Problem Reporting

One of the new features that will be released with 0.9.7 is the new problem reporting feature. Although this feature is orthogonal to the functionality directly in m2e I think this is the most critical addition we have made in some months. With one click you will be able to gather up your logs and system information and automatically submit that information to our issue tracking system. We want to accurately capture the information from problems as quickly as possible so users get correct information to us quickly. We are also making tools on our side to process these automated problem submissions so we can determine what’s wrong faster. This functionality is already present in the code base and will be in the next dev build and in 0.9.7. We took a page out of Joel Spolsky’s book:

https://fogbugz.bitvise.com/help/Articles/GetCrashReportsFromUsersA.html

Architecture

We are going to be working on the architecture of m2e to allow the clear separation of dependency management, the configuration framework, and the Maven life cycle. Right now a great number of our problems can be attributed to some muddling in this area. We made a first attempt and we see now how things internally need to change. The separation of the dependency management means that you will be able to use this feature by itself on non-Maven projects if you wish.

The configuration framework will be responsible for taking configuration in POMs and mapping that into Eclipse, but it will also be responsible for taking preferences in Eclipse and mapping those into POMs. Currently we are working on Flex integration for a client and this is the first case of having fully bidirectional configuration management. You change the POM and Eclipse preferences are changed, you change the Eclipse preferences and the POM is updated to reflect those changes.  These are what we call configurators and we will document how these work so that people can create their own bidirectional support for any tool they wish to support.

The Maven lifecycle work will focus on optimizing what Maven itself actually does. Igor is currently working on some prototypes for a limited set of use cases to make the workflow as efficient as possible. In a session with a client they reported that Maven always seems to be “pulsing”, that the life cycle is always being fired and slowing things down/consumes a lot of resources. Igor is trying to work from concrete scenarios which will help me understand what needs to be changed in Maven 3.x itself to support a Maven integration that is not so invasive and resource-hungry.

Features and Improvements

As I stated earlier, we are going to limit much of the new feature work in order to support the testing and quality aspects of m2e. But what we would like to do is capture what users are asking for in major categories like:

• Extension points for integration
• WTP functionality
• POM Editor functionality
• Tight integration with Nexus

This is the kind of information we will be looking for during the 0.9.8 iteration and, once decided, those will be the final targets for the 1.0 release. We will be looking for accurate user stories and we will be using the voting mechanism in JIRA to help us decide. We are looking to be fairly aggressive on the 1.0 schedule which we will be able to do once the testing is in place. As such we will likely time-box the releases and we’ll do as much as we can in a fixed period of time and then release. This will be easier as Rich automates more of the testing.

Convergence with Maven 3.x

As many users know we are using a version of the Maven Embedder from 4 months ago which at the time was Maven 2.1.x. In Maven, we now have a 3.x, 2.1.x, and 2.0.x branch and m2e is working from the 3.x branch. Given that we’re 4 months behind and the testing is not adequate to just slot in what we currently have on the trunk (3.x). We need to be cautious about absorbing those changes. Right now Shane and Benjamin Bentmann are almost entirely adding unit and integration tests to the Maven 3.x code base so that we can safely do this. We are about to release Maven 3.0 alpha-2 (the alpha-1 was quiet) and I imagine that around alpha-5 the testing on the Maven side will converge with the testing efforts here and we will be able to start using what’s on Maven trunk. What we are going to do is create a branch where we will integrate Maven trunk for those that want to try it but it won’t be something we suggest for daily use but will be available for the adventurous.

One of the biggest changes that we’ve made in Maven 3.x is the integration of Mercury which is the next generation of our repository management & transport APIs. We really don’t want to try and integrate Maven trunk into m2e proper until Mercury is properly integrated into Maven trunk itself. It’s a very big change which is why we need all the testing. We believe that Mercury is the only real way we can improve Maven 3.x itself so there are big changes but the long-term benefit is a big win. The artifact resolution will be deadly accurate and fast. If you want to know more about Mercury you can take a look at Oleg’s blog:

http://blogs.sonatype.com/people/author/oleg/

Project Infrastructure

We are going to be making to be making some infrastructure changes to help us organize the project better and hopefully make it easier for users to participate. Starting next week, daily builds will be available for people. As we fix issues, the builds will be available for people to try.

We are going to start using the same reporting infrastructure that we use for Maven so that we can track what users want. This is what we are currently using for Maven itself and so I would encourage users to start voting on issues and features they care about as we’ll start scheduling time to fix the issues and features with the highest vote counts. If you want to take a look at the actual reports you can take a look here:

http://www.sonatype.org/~j2ee-hudson/reports/maven-votes.html http://www.sonatype.org/~j2ee-hudson/reports/plugin-votes.html

We are going to make a big pass this week at triaging all the issue currently in our Codehaus JIRA instance because we want to reduce the issue count because we are going to migrate all our issues to the Sonatype JIRA instance. We want to do this because we have some reporting tools and plugins (like Green Hopper) which are not available at Codehaus. We also need to do this so that we can synchronize this with our problem reporting and error submission system. We are basically going to let users automatically submit issues with the data attached and we need to be able to move these issues around. Trying to move an issues from one JIRA instance to another is a real pain in the ass. We are going to take care of migrating the issues and users so there should be minimal impact to users. We will test the migration several times before we do it for real.

People also want to know about what’s happening with the move to Eclipse. We are definitely going to do this and Sonatype is a strategic development partner so this is certainly going to happen. After some discussions with folks at Eclipse we have decided to move to Eclipse after the 1.0. There are a couple reasons for this: the first is that we want to focus on testing and quality and some architectural changes will change the dependencies and this impacts the legal work we need to do. Basically we want to focus on getting a quality 1.0 out and then we’ll worry about moving to Eclipse. Moving to Eclipse incurs a lot of overhead and we just have to set some priorities and a high quality 1.0 of m2e is a higher priority for us.