Maven 3.0: The Future of Maven
Currently, preview releases of Maven 3 are available to download from the Maven website and, with a final release of Maven 3 expected for the second quarter of this year, JAXenter caught up with Jason van Zyl to ask him if Maven users should be making any preparations, ready for the Maven 3 launch……
Jason van Zyl
Jason van Zyl is the Founder and CTO of Sonatype, the leader in Java development infrastructure whose customers include Intuit, Cisco, Qualcomm, Vanguard and E*Trade. Jason has over 10 years of experience in open source and proprietary enterprise software development. An open source enthusiast, Jason is the founder of the Apache Maven project, and the original benefactor of the Nexus and M2Eclipse projects. Jason currently serves as Chair of the Apache Maven Project Management Committee. He has been involved with the Apache Software Foundation (ASF) for seven years, helped to found Codehaus, a well respected incubation facility for open source community projects, and is a frequent speaker at many major software conferences, including JavaOne, EclipseCon, EmergingTech, and ApacheCon.
JAXenter: With the switch from Maven 1.x to 2, developers had to manage some fundamental changes. What challenges can users expect when migrating from Maven 2 to Maven 3?
Jason van Zyl: We are planning that, in most cases, Maven 3.0 will be a drop-in replacement for Maven 2.x. We have gone to great lengths to ensure backward compatibility while reimplementing a good portion of Maven’s internals. From the command-line perspective, we are trying to be fully compatible. Maven 3.0 will not allow duplicate dependency or plugin declarations, so those problems will need to be fixed, but aside from that no changes to your POMs will be required. In all other regards we have created backward compatibility layers to protect users from the many internal API changes that we have made. I really hope that the Maven community can move forward to Maven 3.0 without grief, and use the new features as it convenient for them.
JAXenter: Is there anything users should keep in mind when creating a new project, to be prepared for Maven 3?
Jason van Zyl: It honesty shouldn’t be any different from Maven 2.0. That’s the intended goal. So much has changed under the covers, that we didn’t want to change the POM format. The primary goal is a way forward for all Maven users, efficient embedding, increased performance, synchronizing the Maven 3.0 code base with m2eclipse, and adding extension points for tools like Tycho, Polyglot Maven, and the Maven Shell.
JAXenter: Will Maven 3 support the integration of dynamic languages (e.g Groovy)?
Jason van Zyl: It would be more accurate to say that Maven 3.x can support dynamic languages. This will not be directly available in the Maven 3.0 release, but support for dynamic languages is available now in Sonatype’s Polyglot Maven project.
JAXenter: Will there still be a settings.xml or can we expect another method of configuration in Maven 3?
Jason van Zyl: In Maven 3.0 we are again not attempting to change the models that users are accustom to. Internally in Maven 3.1, we will expose a security manager and use the settings.xml implementation as the default implementation, but Sonatype is planning on creating an implementation that interacts with Nexus, our repository manager. In dealing with many large organizations we have found that integrating with in-house security systems and custom implementations is necessary so we will be providing an extension point for this with the security manager.
In Maven 3.1 we will also introduce POM mixins to help make configuration more maintainable and portable. One of the frequent complaints about Maven 2.0 is that sharing configuration can only be done via inheritance. This is obviously problematic as not all projects within organizations, and certainly not all projects in OSS, share lineage. POM mixins are a form of POM composition where a parameterized fragment of a POM can be injected into the current POM with a simple reference.
For me, the first mixin that I wanted to create was a mixin to encapsulate a standard release capability for Maven projects. Apache projects that use Maven, inherit the Apache POM, which contains configuration for our release process. This incorporates license attribution, PGP signing, staging and promotion with Nexus, an Apache compliant source archive containing the original project structure, and the production of the standard source and javadoc JARs. I wanted to create a very easy way for any project to incorporate this capability in their project. The release mixin consists of plugin declarations, their configuration – which can be parameterized – and a specification of what POM elements are required in the target POM for the mixin to operate correctly. The POM mixins can then be deployed to a remote Maven repository to be shared via a standard Maven coordinate. In the target POM, you specify the coordinate of the POM mixin along with any parameters required by the POM mixing, and Maven will retrieve the POM mixin and inject it into the target POM.
What I expect to see are projects in the community creating mixins for capabilities that require the interaction of many plugins, along with the accompanying configuration. One of the biggest problems in Maven, given it’s distributed nature and there being so many plugins, is finding the right plugins that work together and figuring out how to configure a set of plugins to arrive at the desired result. The POM mixins will remove much of this pain.
JAXenter: Can you tell us a bit about Nexus?
Jason van Zyl: I’m going to let Brian Fox, Nexus lead and Maven PMC Chair, answer this one:
Brian Fox: Nexus is a repository manager built by the Maven experts at Sonatype. Repository managers serve a few purposes within an organization: they act as highly configurable caching proxies for remote repositories, and they provide a centralized location to deploy, store, index and share all your internal artifacts. We use the analogy that a repository manager is to binaries, what a source control management system is to sources. In both cases you can use a flat file system, but you’ll quickly learn that this isn’t scalable.
Nexus is unique among repository managers for several reasons. First, it is designed to be light on resources and heavy on performance. Second, the data is stored in the native repository layout on disk, which ensures that traditional backup and synchronization tools can be used. You don’t need to be a DBA to get access to your artifacts. Third, Nexus supports many repository formats and can convert on the fly between them: Maven 1, Maven 2, OSGI Bundle Repository (OBR), P2, RubyGems. The community is even working on RPM support.
Nexus is the preferred choice for the largest repositories in the community such as Apache, Codehaus, Jboss, Atlassian, Glassfish and many others. It is available in two flavors: an open source version and a professional version that extends the open source version with commercial add ons, to further manage the binary lifecycle in enterprise organizations.
JAXenter: In the Maven Repository, there are all kinds of plug-ins, ranging from early Alpha-Versions to stable plug-ins. Do you have any plans for bringing order to this “plug-in chaos”? One could imagine a similar process to Eclipse, with Incubators and a Simultaneous Release Train providing reliable, high quality plug-ins…..
Jason van Zyl: This is something that Sonatype plans to tackle in the near future, where we provide a higher quality set of plugins. Maven, by it’s distributed nature, makes it pretty hard for us to guarantee the quality of Maven plug-ins in every Maven repository around the world and what ultimately lands in Maven Central. But what we can do is “battle test” a smaller set of plug-ins and make sure they have integration tests, perform well, and integrate properly with m2eclipse. Once Maven 3.0, m2eclipse 1.0, and Tycho 1.0 are released we plan to start this project.
Read the Second Part of our Jason van Zyl interview – coming soon!