Blog Xebia France

Devoxx Day 4 Maven Reloaded

Jason van Zyl, the emblematic leader plan Maven, was present in Devoxx to introduce novelties to come in environment Maven: Maven 3.0 and 3.1, revision of M2ECLIPSE, improvements to come on Nexus; contents were dense.

He begins his presentation by apologising for the version 1.0 Maven which raised experimentation and was not intended for such broadcasting. Version 2.0 introduced as for her many defects, he also admits him. He promises then a tool mature and succeeded with Maven 3.0.

Plan stagnated during several years leaving the place in no major improvement. The complexity of the source code of Maven, based on Plexus, a container of injection of dependency which is peculiar to it, is partly reason there. Jason van Zyl explains so that few developers contribute to the core of plan, by comparison with the broad community working on plugins.

This inactivity linked to the defects of Maven 2.0 drove to the creation of many alternative plans which win in popularity: Ivy, Gradle, ... On this subject, the leader of plan Maven sees this competition as advantageous but stresses the need to keep a compatibility between artefacts produced by all these tools.

What makes Sonatype?

Sonatype was created several years ago by Jason van Zyl. Beyond Maven, the firm contributes to many plans:

• M2ECLIPSE: the plugin Maven principal for Eclipse, his direct rival Eclipse IAM being still at the embryonic stadium
• : a repository Maven
• Hudson: a server of very popular uninterrupted integration
• Tycho: a plugin Maven for development Eclipse and OSGI
• Flexmojos: group of plugins Maven for development Flex
• Pax: a plugin Maven for OSGI
• Maven-bundle-plugin: a plugin Maven making easier the creation of bundle OSGI

Maven 3.0: polyglot and more competitive

As explained in introduction, this new version will constitute an important evolution for Maven. Jason van Zyl announces a revision around the end of January, 2010.

Ascending compatibility

Due to the very large use of Maven, ascending compatibility is inevitable.

So, Jason van Zyl explains that many tests of integration were accomplished to assure that all plans Maven 2.0 will be entirely compatible with Maven 3.0. The majority of the plugins will be compatible without rewriting. However, some modifications of IPA - INTERNATIONAL PHONETIC ALPHABET introduced into Maven 3.0 will not be able to be compensated by the mechanisms set up of compatibility.

In practice, it is therefore possible to expect a stage of starting during which each of the teams which support from plugins will have to assurrer their compatibility with Maven 3.0.

Improvements

Multi-thread e execution

A little before Devoxx, Jason van Zyl announced on the blog of Sonatype that the simplifications of architecture brought by Maven 3.0 had allowed to implement an improvement hoped for a long time: the execution of the build on several threads.

In a context where the building of a plan of firm with Maven can very often take several minutes, this improvement will be able to give proof to her only migration towards Maven 3.0.

Composition of POM with mixins

mixins will be introduced into Maven 3.0. They will allow to create POM by composition, every imported fragment can so be displayed as artefact. The numerous inheritance which mixins constitutes will be lin aris e inside to find a chaine of simple inheritance.

Simplification of integration

A better integration to M2ECLIPSE will allow builds incr mentaux avoiding so of r - to carry out the whole cycle of life every time. Maven 3.0 will also give points of extension for the cycle of life. It will be so possible to define actions to be carried out before and after the whole cycle of life. Finally, Maven will be more easily included into IDES or into servers of uninterrupted integration, by allowing a better control of the behaviour by his guest.

Polyglot Maven

It will be possible to write POMS in another language than XML. The structure of data will remain identical, but it will be possible to use the syntax of GROOVY, Ruby, La Scala, Python or YAML. It will be possible to transform POMS of a representation in other what will allow to assure compatibility at the level of the repository always by displaying POM there in XML. Since then, the choice of representation will depend on preferences of the developers.

Example below shows simple POM represented in GROOVY:

Polyglot Maven will not be standard in Maven 3.0, it will be about an extension.

Maven Shell

Maven Shell is an at least unexpected extension but which proved to be persuasive. It is about an environment of execution for Maven who, in its interactive version, allows to the user to grab its Maven orders as in the Shell native of its operating system. All interest is then the benefit of performance which it is possible to accomplish thanks to conservation in mask of the data of the reactor Maven between every execution.

Demonstration of Jason van Zyl: a first execution of the build in 14 seconds, he restarts then the same order a second time in only 7 seconds.

Maven Shell also gives an interactive environment with many additional orders, simplifying the common tasks Maven. He will be able to be included in Hudson and in Nexus to give in these servers of functionality more powerful Maven.

Maven 3.1: the arrival of Guice

Plexus, the container of injection of historical dependency of Maven, will be replaced by in Maven 3.1. This simple decision will have the effect of simplifying the legibility of the source code, the development of plugins, and therefore of enlarging the community of developers working on plan. Jason van Zyl explains to want to be based at the farthest on JSR 330 (DEPENDENCY INJECTION FOR POPULAR DANCE).

Peaberry, the extension OSGI of Guice, will be also used, what will bring to Maven a modularit standardised for its plugins.

Where all novelties introduced by Maven 3.0 allow ascending compatibility, Maven 3.1 will be more audacious. So, it is possible to expect a more important evolution of the model of plan (POM). The compatibility at the level of the repository will continue being assured with the clients Maven 2.0.

To be able to continue capitalising on the important mass of code accomplished for Plexus, an extension for Guice was developed to assure the integration of components historical Plexus in the container Guice.

No date is pointed out for the moment for this version 3.1.

M2ECLIPSE and Nexus

M2ECLIPSE, the plugin Eclipse who brings the support of Maven with Eclipse, fate of its gestation and is soon going to be finalised. Jason van Zyl assures that many problems of stability and of behaviour with big plans Maven are corrected. The integration more pushed in IDE that will allow Maven 3.0 should also improve the ergonomics of this plugin.

Nexus, from his part, also go to leave Plexus to the advantage of Guice and Peaberry. This migration will intervene besides in first on Nexus, Maven 3.1 will follow.

Conclusion

Maven is in general a sulphurous subject in the community Popular dance. His leader, Jason van Zyl, makes him even unanimity and .

Nonetheless, it is well necessary to admit that construction sites hired on Maven are this time very real. Made demonstrations proved to be persuasive, even if only the practical implementation will allow to judge this new version.

Not enough currently available information on Maven 3 except some tickets on the blog of Sonatype will however be regretted.