When training the Maven Fundamentals or Advanced Maven Techniques classes or reading the Apache Maven users mailing list, it seems that again and again Maven 2 pops up. Sometimes even the long dead Maven 1 creeps up now and then. Usually my first two questions to somebody using Maven 2 are Why? and Are you sure?
m2e 1.1 has been released as part of Eclipse Juno release this week. If you haven’t heard about Eclipse Juno, you should take a look. Eclipse 4.2 IDE for Java Developers includes m2e by default. If you use Maven and Nexus, download Eclipse 4.2 today.
Noteworthy in this version:
m2e 1.1 is already included in “Eclipse IDE for Java Developers” package available from http://eclipse.org/downloads/ or it can be installed from the Eclipse Juno release repository. Eclipse 3.7/Indigo users can install the new version from the m2e release repository
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.
Two weeks ago we proposed that [Hudson plugin authors be able to use dependency injection][1] through the JSR-330 standard. This change makes it easier to write Hudson plugins without having to dig into Hudson internals, it provides greater separation between plugins and Hudson core, and it makes it much easier to test plugins without having to bring along core Hudson objects.
These changes are now [in the core of Hudson][2]. Even though JSR330 can now be used by plugin authors these changes should, in no way, affect plugin authors using the existing API. Since this question came up on the mailing list, I’ll give a short description of how it works here. The JSR330 integration allows you to take advantage of JSR330, if you wish, by using an alternative plugin strategy. Our new plugin strategy interoperates with the existing, classic plugin strategy. Sonatype’s Hudson Professional distribution actually ships with a mixture of JSR330 plugins and classic plugins and we find this works quite well. We tried to make it easier to use new strategies for wiring up plugin, and [Stuart McCulloch has offered this strategy on the Jenkins development list][3] and it appears to have been absorbed as part of [JENKINS-8897][4]. Continue reading
