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.
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.
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.
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
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.
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:
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.
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/
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.
