Publié par
Il y a 8 années · 7 minutes · Java / JEE

Devoxx – Jour 4 – Maven Reloaded

Jason van Zyl, le leader emblématique du projet Maven, était présent à Devoxx pour présenter les nouveautés à venir dans l’environnement Maven : Maven 3.0 et 3.1, finalisation de M2Eclipse, améliorations à venir sur Nexus ; le contenu était dense.

Il commence sa présentation en s’excusant pour la version 1.0 de Maven qui relevait de l’expérimentation et n’était pas destinée à une telle diffusion. La version 2.0 présentait quant à elle de nombreux défauts, il le reconnaît également. Il promet alors un outil mature et abouti avec Maven 3.0.

Le projet a stagné pendant plusieurs années ne laissant la place à aucune amélioration majeure. La complexité du code source de Maven, basé sur Plexus, un conteneur d’injection de dépendances qui lui est propre, en est pour partie la raison. Jason van Zyl explique ainsi que peu de développeurs contribuent au core du projet, en comparaison de la large communauté travaillant sur des plugins.

Cette stagnation liée aux défauts de Maven 2.0 a conduit à la création de nombreux projets alternatifs qui gagnent en popularité : Ivy, Gradle, Buildr, … A ce sujet, le leader du projet Maven voit cette concurrence comme bénéfique mais insiste sur le besoin de conserver une compatibilité entre les artefacts produits par l’ensemble de ces outils.

Que fait Sonatype ?

Sonatype a été créé il y a plusieurs années par Jason van Zyl. Au-delà de Maven, l’entreprise contribue à de nombreux projets :

  • M2Eclipse : le principal plugin Maven pour Eclipse, son concurrent direct Eclipse IAM étant encore au stade embryonnaire
  • Nexus : un repository Maven
  • Hudson : un serveur d’intégration continue très populaire
  • Tycho : un plugin Maven pour le développement Eclipse et OSGi
  • Flexmojos : un ensemble de plugins Maven pour le développement Flex
  • Pax : un plugin Maven pour OSGi
  • Maven-bundle-plugin : un plugin Maven facilitant la création de bundle OSGi

Maven 3.0 : polyglotte et plus performant

Comme expliqué en introduction, cette nouvelle version constituera une évolution importante pour Maven. Jason van Zyl annonce une finalisation autour de fin janvier 2010.

Compatibilité ascendante

Du fait de la très vaste utilisation de Maven, la compatibilité ascendante est incontournable.

Ainsi, Jason van Zyl explique que de nombreux tests d’intégration ont été réalisés afin d’assurer que l’ensemble des projets Maven 2.0 seront entièrement compatibles avec Maven 3.0. La majorité des plugins seront compatibles sans réécriture. Toutefois, certaines modifications d’API introduites dans Maven 3.0 ne pourront être compensées par les mécanismes de compatibilité mis en place.

Dans la pratique, on peut donc s’attendre à une phase de démarrage pendant laquelle chacune des équipes qui maintiennent des plugins devront assurrer leur compatibilité avec Maven 3.0.

Améliorations

Exécution multi-threadée

Peu avant Devoxx, Jason van Zyl annonçait sur le blog de Sonatype que les simplifications d’architecture apportées par Maven 3.0 avaient permis de mettre en œuvre une amélioration espérée depuis longtemps : l’exécution du build sur plusieurs threads.

Dans un contexte où la construction d’un projet d’entreprise avec Maven peut très souvent prendre plusieurs minutes, cette amélioration pourra justifier à elle seule la migration vers Maven 3.0.

Composition de POM avec les mixins

Les mixins seront introduit dans Maven 3.0. Ils permettront de créer des POM par composition, chaque fragment importé peut ainsi être déployé en tant qu’artefact. L’héritage multiple que les mixins constituent sera linéarisée en interne afin de retrouver une chaine d’héritage simple.

Simplification de l’intégration

Une meilleure intégration à M2Eclipse permettra des builds incrémentaux évitant ainsi de ré-exécuter l’ensemble du cycle de vie à chaque fois. Maven 3.0 offrira également des points d’extension pour le cycle de vie. Il sera ainsi possible de définir des actions à exécuter avant et après l’ensemble du cycle de vie. Enfin, Maven sera plus facilement intégré dans les IDEs ou dans les serveurs d’intégration continue, en permettant un meilleur contrôle de son comportement par son hôte.

Polyglot Maven

Il sera possible d’écrire les POMs dans un autre langage que XML. La structure de données restera identique, mais il sera possible d’utiliser la syntaxe de Groovy, Ruby, Scala, Python ou YAML. Il sera possible de transformer les POMs d’une représentation à l’autre ce qui permettra d’assurer la compatibilité au niveau du repository en y déployant toujours un POM en XML. Dès lors, le choix de la représentation dépendra des préférences des développeurs.

L’exemple ci-dessous montre un POM simple représenté en Groovy :

project {
    modelVersion '4.0.0'
    parent {
        artifactId 'xebia-parent'
        groupId 'fr.xebia'
        version '1.0.0-SNAPSHOT'
    }
    artifactId 'xebia-polyglotmaven-test'
    version '1.0.0-SNAPSHOT'
    name 'Polyglot Maven Test'
    url 'http://blog.xebia.fr'
    build {
        testResources {
            testResource {
                filtering 'true'
                directory 'src/test/resources'
            }
        }
    }
    dependencies {
        dependency {
            groupId 'junit'
            artifactId 'junit'
            version '4.7'
            scope 'test'
        }
    }
}

Polyglot Maven ne sera pas en standard dans Maven 3.0, il s’agira d’une extension.

Maven Shell

Le Maven Shell est une extension pour le moins inattendue mais qui s’est montrée convaincante. Il s’agit d’un environnement d’exécution pour Maven qui, dans sa version interactive, permet à l’utilisateur de saisir ses commandes Maven comme dans le shell natif de son système d’exploitation. Tout l’intérêt est alors le gain de performance qu’il est possible de réaliser grâce à la conservation en cache des données du reactor Maven entre chaque exécution.

Démonstration de Jason van Zyl: une première exécution du build en 14 secondes, il relance alors la même commande une seconde fois en seulement 7 secondes.

Maven Shell offre également un environnement interactif avec des nombreuses commandes supplémentaires, simplifiant les tâches Maven courantes. Il pourra être intégré à Hudson et à Nexus pour faire bénéficier à ces serveurs de fonctionnalités Maven plus puissantes.

Maven 3.1 : l’arrivée de Guice

Plexus, le conteneur d’injection de dépendance historique de Maven, sera remplacé par Guice dans Maven 3.1. Cette simple décision aura pour conséquence de simplifier la lisibilité du code source, le développement des plugins, et donc d’élargir la communauté de développeurs travaillant sur le projet. Jason van Zyl explique vouloir se baser au maximum sur la JSR 330 (Dependency Injection for Java).

Peaberry, l’extension OSGi de Guice, sera également utilisée, ce qui apportera à Maven une modularité standardisée pour ses plugins.

Là où l’ensemble des nouveautés introduites par Maven 3.0 permettent la compatibilité ascendante, Maven 3.1 sera plus audacieux. Ainsi, on peut s’attendre à une évolution plus importante du modèle de projet (POM). La compatibilité au niveau du repository continuera d’être assurée avec les clients Maven 2.0.

Afin de pouvoir continuer à capitaliser sur la masse importante de code réalisé pour Plexus, une extension pour Guice a été développée pour assurer l’intégration des composants Plexus historiques dans le conteneur Guice.

Aucune date n’est pour le moment indiquée pour cette version 3.1.

M2Eclipse et Nexus

M2Eclipse, le plugin Eclipse qui apporte le support de Maven à Eclipse, sort de sa gestation et va bientôt être finalisé. Jason van Zyl assure que les nombreux problèmes de stabilité et de comportement avec les gros projets Maven sont corrigés. L’intégration plus poussée à l’IDE que permettra Maven 3.0 devrait elle aussi améliorer l’ergonomie de ce plugin.

Nexus, pour sa part, va lui aussi abandonner Plexus au profit de Guice et Peaberry. Cette migration interviendra d’ailleurs en premier sur Nexus, Maven 3.1 suivra.

Conclusion

Maven est en général un sujet sulfureux dans la communauté Java. Son leader, Jason van Zyl, ne fait lui même pas l’unanimité et sa présentation a été diversement appréciée.

Malgré tout, il faut bien reconnaître que les chantiers engagés sur Maven sont cette fois bien réels. Les démonstrations faites se sont montrées convaincantes, même si seule la mise en œuvre pratique permettra de juger de cette nouvelle version.

On regrettera tout de même le peu d’information actuellement disponible sur Maven 3 en dehors de quelques billets sur le blog de Sonatype.

Michaël Figuière
Michaël est consultant chez Xebia où il intervient notamment sur des sites Web à fort trafic. A son aise tant avec les environnements JEE qu'avec les technologies de plus bas niveau, il est spécialisé dans les architectures distribuées et les technologies innovantes telles que NoSQL, les moteurs de recherche, ou encore le data mining.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *