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.