Jason van Zyl

The Future of Maven Part 2

Jessica Thornsby
The-Future-of-Maven-Part-2

In part two of our interview, JAXenter asks Jason van Zyl about m2eclipse, the P2 project, Polyglot Maven, and whether we might see a merger between IAM and m2eclipse, in the future…….

JAXenter: Sonatype have just released version
0.10.0 of their m2eclipse Maven Plug-in for Eclipse. What new features
does 0.10.0 have to offer? And will version 1.0 bring major
changes?

Jason van Zyl: m2eclipse 0.10.0 is almost a
complete rewrite from 0.9.8, so there are many changes and
improvements. The most important aspect is that we have the
m2eclipse code base synchronized with the Maven 3.x code base. When
we need fixes in m2eclipse that are the result of problems in
Maven, it’s only a matter of hours before we can roll a fix through
the system and produce a new m2eclipse build. There have been
several hundred fixes across Maven and m2eclipse in the last year.
We’ve probably put in close to eight thousand man hours across
Maven and m2eclipse as we approach the Maven 3.0 and m2eclipse 1.0
releases.

The performance will be the first thing users notice. Even with
a standard Maven project general operation is faster, but if you
leverage the new incremental Maven Plugin API and the customizable
lifecycle mapping, you truly have incremental behavior with Maven
inside of Eclipse.

The new incremental Maven Plugin APIs allow Eclipse to
communicate very precise information back to Maven. For example, if
you change a single resource that needs to be filtered, Eclipse
will no longer trigger Maven’s entire lifecycle, but rather
communicate the information about the single file that has changed,
and execute Maven’s resource plugin to operate on the single file
that changed. The customizable lifecycle mapping allows m2eclipse
to eliminate most of Maven’s execution from within Eclipse. You can
selectively choose what plugins you want to execute as part of the
build within Eclipse. The end result is that if you tune your
project, you can get extremely fast results. We want to make this
tuning easier as we move toward the 1.0 release, but it’s still
relatively easy to do this today.

We also have improved integration with Nexus so you can search
the content of your repositories from within Eclipse, and we have
simplified the configuration of repository indexes by automatically
configuring them based on repositories you have configured in your
settings.xml file.

JAXenter: There’s already an official Eclipse
project for integrating Maven: IAM (formerly
‘Q4E’). What’s the difference between m2eclipse and IAM? And is a
merger of the two projects conceivable?

Jason van Zyl: IAM is not the official project
for integrating Maven. Both m2eclipse and IAM are in incubation, so
neither has official status at Eclipse. It’s unlikely there will be
a merger. The IAM code base is a year behind m2eclipse at this
point, and there are no active Maven 3.x committers on the IAM
team. Sonatype has full-time developers and QA staff on Maven 3.x
and m2eclipse. We’ve done a lot of work over the last year to make
sure Maven and Eclipse work well together. m2eclipse is the de
facto standard. You can see this in the community as questions on
the user mailing lists are always about m2eclipse, and vendor
support is already in place for m2eclipse – Genuitec, JBoss, and
SpringSource all integrate m2eclipse, not IAM. Eclipse may
ultimately let both projects graduate from incubation, but only one
project will be official and shipped with distributions, and it
very likely that will be m2eclipse. It simply boils down to
manpower. We always hope for community support, but at any given
time Sonatype has up to eight full-time people working on m2eclipse
so users can be assured bugs will be fixed and new features will be
developed.

JAXenter: Can you tell us a bit about the P2
project at Eclipse and how Sonatype has become involved with the P2
project.

Jason van Zyl: The P2 project at Eclipse is the
basis of the update manager in Eclipse, but it is also a general
purpose provisioning framework. Sonatype is interested in
provisioning user desktops, provisioning development
infrastructures, and provisioning production run-times. P2 has
become a critical technology for Sonatype, so we recently hired
Pascal Rapicault, who is the lead of the P2 project at Eclipse.
Pascal will remain heavily involved in the community, in much the
same way that Sonatype is heavily involved in the Maven community.
We are also planning to invest in some research and collaborate
with Daniel Le Berre through the National Centre for Scientific
Research in France. Daniel is the creator of SAT4J, which is the
core solver used in P2 for determining the selection of
dependencies. I am interested in trying to merge the artifact
resolution strategies of Maven and P2.

JAXenter: Maven Tycho is your new OSGi-Toolchain designed
to be a drop-in replacement for the Eclipse PDE Build. What are the
goals of the Tycho project? And what features are already
available?

Jason van Zyl: The focus of Tycho is to create
an effective hybrid of Maven and Eclipse-based OSGi technologies
for building, publishing, and distributing Eclipse plugins, update
sites, RCP applications and OSGi bundles. Tycho is a manifest-first
approach to building and leverages Eclipse’s Equinox, JDT and P2
projects. The alternate approach is a POM-first approach which is
the strategy employed by the Maven Bundle Plugin, which uses Peter
Krien’s BND tool to generate a manifest from the classes post
build.

Both of these approaches will be with us for quite a while so
another goal of Tycho is to allow these different approaches to
interoperate. Both approaches produce bundles, but in order to use
Tycho, the bundles must be available in a P2 repository and have
the accompanying P2 metadata. So, with a POM-first approach we
dynamically generate the required P2 metadata for bundles that do
not have it. This effectively allows us to take all bundles
available in Maven Central and allow them to be used within Tycho.
I believe that an unmanageable rift will form if tools are not
capable of interoperability between these two common forms of
development. Many people use Maven only to produce bundles, and
many people use standard Eclipse-based technologies to produce
bundles, and if these worlds are not united there will be a massive
duplication of effort. Tycho is a bridge between these two
worlds.

We have also integrated Tycho with m2eclipse so that you can
import a Tycho project into Eclipse as a PDE project. We have added
support to allow the resolution of POM-first bundles in the Eclipse
workspace. Currently there are two major projects at Eclipse that
are using Tycho to build: the Tigerstripe project driven by Cisco, and the EGit project.
The EGit project is interesting because it uses the hybrid approach
of using a POM-first build for JGit, we then generate a P2
repository from the Tycho build which is then consumed by the EGit
build which uses a manifest-first Tycho build.

JAXenter: Can you tell us a bit about Polyglot
Maven
?

Jason van Zyl: Polyglot Maven is the project
for experimenting with domain specific languages (DSLs) and terse
markup languages (TSLs) in conjunction with Maven 3.x’s core. What
is currently available today can be found at http://polyglot.sonatype.org. What we have are
starting points of internal DSLs for Groovy, Ruby, Scala, and
Clojure. There is also an external DSL that I have developed using
XText,
which is a fantastic tool at Eclipse.org for creating parsers and
editors for external DSLs. We are also providing support for
YAML-based POMs using the excellent SnakeYAML library.

The DSLs are meant to be more then merely different
representations of the POM. The DSLs will have full access to
Maven’s internals, which have been redesigned for integration and
extension. What this means in practical terms is that implementors
of DSLs can leverage Maven’s infrastructure but create custom ways
to interact with, or extend, Maven. A DSL could change Maven’s
lifecycle, decorate lifecycle phases, create new configuration
mechanisms, or allow a more procedural mechanism for their users. I
honestly don’t know how useful these features are for general
users, and more specifically enterprise users, but I only see
benefits in allowing greater leverage of Maven’s
infrastructure.

What I really care about and what really concerns me is
interoperability at the repository level and tooling. This is why
the code lives in the Polyglot Maven project. I don’t want to
misrepresent to users that this is ready for prime time. It fully
works, but there needs to be more thought about how projects being
constructed with possibly many DSLs can still play nicely together.
What will the resultant metadata look like that is exported to
Maven repositories? Currently we feel that this is likely to be a
Maven 2.x POM created during the deployment process. What will the
tooling look like for Maven DSLs? We are hoping that the DSLs can
preserve many of Maven’s internal models so that they can leverage
m2eclipse. To simply provide the infrastructure for these DSLs is
not enough; repository interoperability and tooling is
important.

In the last 18 months I have surveyed nearly 2000 people from
the various talks and presentation I’ve given, and approximately 5%
of the people surveyed are interested in DSLs for Maven or
different representations of the POM. But these 5% are very
important. These are the very creative hackers that want to do
things in a project from one end to the other in a fully
programmatic way. They want to code everything including the build.
This is why I created Polyglot Maven because I believe this 5% can
potentially contribute as much to Maven as the remaining 95% of the
Maven user base. The folks who want the polyglot support are highly
effective people. In the end it’s all good for Maven.

JAXenter: Can you tell us a bit about the
Maven
Shell
?

Jason van Zyl: The Maven Shell is Maven
embedded in a long-lived shell process. The shell avoids the
start-up costs of invoking Maven repeatedly, caches the parsed
POMs, provides Maven Archetype integration, provides Nexus
integration, has a built in help system, and on the OS X provides
Growl support. In typical cases you’ll see your build times cut in
half. We have many features planned for the 1.0, such as the
integration of the make-like reactor mode so that within the shell
only the modules that have changed will be built, project workflow
support to help guide users to the right thing, Hudson support for
creating jobs and querying statuses, and ultimately the integration
of Tycho and Polyglot Maven features.

JAXenter: There are many different build
systems to choose from. In your opinion, which is Maven’s biggest
competitor? Maybe Gradle…..?

Jason van Zyl: Maven’s biggest competitor in
the enterprise are homegrown Maven-like solutions created with Ant.
These are the systems that Maven typically replaces in enterprise
settings. We honestly don’t see anyone trying things like Gradle or
Buildr for large enterprise projects. I think there is a lot of
hype around some of these technologies. We understand that people
are constantly looking for new solutions, but we’re also convinced
that the enterprise build space is full of complicating factors
that don’t lend themselves to over-simplification.

Author
Comments
comments powered by Disqus