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……
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
JAXenter: Is there anything users should keep
in mind when creating a new project, to be prepared for Maven
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
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
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
JAXenter: Can you tell us a bit about
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
Read the Second Part of our Jason van Zyl interview –