Howdy,
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 (http://nexus.sonatype.org) 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. 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.
o 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.
o 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.
o 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
o 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.
o 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.
o 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/
o 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 what the actual reports might
lookl like 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.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
