Ce qui nous attend avec Maven 3

Maven, premier du nom, est né dans le courant de l'année 2002. Il est en réalité apparu d'abord comme sous-projet du projet Jakarta Alexandria, avant de trouver refuge au sein du projet Apache Turbine. Il est finalement devenu un projet Apache à part entière en 2003. Les défauts de Maven 1 l'ont empêché de véritablement percer dans le monde Java, et finalement assez peu de projets ont migré vers cet outil, aux dépens d'Ant. Jason Van Zyl, le leader de Maven et fondateur de Sonatype (la principale entreprise derrière Maven) a d'ailleurs reconnu que Maven 1 était plus une expérimentation qu'autre chose, lors de la récente conférence Devoxx. C'est d'ailleurs "une chance" que Maven 1 n'ait eu qu'une faible popularité, car son successeur n'offre aucune rétrocompatibilité. Toutefois, Maven 1 a permis de roder les principaux mécanismes de Maven 2, et en particulier son principe de cycle de vie.

Maven 2 sort en version finale à la fin de l'année 2005. Cette version améliore grandement Maven 1 sur de nombreux points : performances, stabilité, fonctionnalités, etc. Maven 2 n'offre toutefois aucune compatibilité avec son prédécesseur, et oblige ainsi les équipes de développement à réécrire tout ou partie de leur fichier de configuration ; le maven.xml ne peut pas être simplement renommé en pom.xml ;) ! C'est certes un point négatif, mais compte tenu de l'adoption plutôt marginale de Maven 1, cela n'a pas été un frein à l'adoption de Maven 2. Ce dernier est effectivement aujourd'hui adopté par une grande partie des projets Java mais laisse encore beaucoup de place à Ant, car la migration de projets gérés par Ant vers Maven est souvent coûteuse et ardue.

Maven 2 souffre encore aujourd'hui d'un certain nombre de problèmes. L'un des reproches que l'on peut lui faire, d'un point de vue technique, est la grande complexité de son noyau. Ceci fait que peu d'évolutions ont finalement été apportées au cœur de Maven 2 durant la vie de ce projet, et que la communauté des développeurs Java s'est peu impliquée dans l'évolution de Maven, hormis par le biais des plugins. Voici une liste non exhaustive des problèmes rencontrés avec Maven 2 :

• Dès que l'on veut sortir un peu du système Maven 2, que l'on veut faire des choses en dehors du cadre de l'outil, ça devient vite complexe.
• Le pom.xml est trop verbeux, par exemple pour la définition dépendances.
• Trop grande utilisation de plugins, y compris pour réaliser certaines tâches simples.
• Documentation "officielle" peu fournie et assez peu intuitive. Heureusement, plusieurs ouvrages complets (et pour certains gratuits) existent !
• XML parfois redondant, même en utilisant l'héritage.
• Support pas encore parfait dans les IDE, bien que les choses s'améliorent.
• Développement et support des plugins "officiels" inégaux.
• Manque de souplesse, de rigueur sur certains principes (difficile de sortir du cycle de vie par exemple).

Maven 3 essaie donc d'adresser, à la plupart de ces problèmes, des solutions dont nous verrons les détails dans les chapitres suivants.

Maven 3 arrive donc à grands pas, afin de combler un certain nombre de lacunes de l'actuelle solution de build Maven 2. Il existe aujourd'hui (début décembre 2009) dans une version alpha-5 disponible au téléchargement. La sortie prévue pour la version finale est janvier 2010. Nous aborderons dans les chapitres suivants les principales nouveautés offertes par cette version.

À noter que les utilisateurs du plugin m2eclipse (plugin offrant le support de Maven 2 à Eclipse) utilisent déjà Maven 3, car ce plugin se base sur cette nouvelle version de l'outil. De même, les dernières versions de NetBeans ou encore d'IntelliJ utilisent cette version de Maven pour construire les projets.

L'un des plus gros chantiers entrepris par l'équipe de développement de Maven 3 concerne la réécriture en grande partie du cœur de l'outil. En effet, Maven 2 a beaucoup souffert d'un code extrêmement lourd de son noyau, rendant ses corrections et ses évolutions difficiles et coûteuses. Un autre inconvénient de cet aspect est la très faible implication de la communauté open source autour du noyau de Maven 2, surtout comparée à son implication dans le développement des plugins. La faute est sans doute liée à certains choix d'architecture discutables, mais également à l'utilisation de Plexus, un framework utilisé au cœur de Maven 2 et dont l'utilisation s'avère plutôt complexe.

On notera également que Maven 3 adopte Java 5 comme base technique, et utilisera dès sa version 3.1 le framework d'injection Google Guice (qui est basé sur la JSR 330 @Inject).

La réécriture du cœur de Maven 3 vise donc à augmenter l'implication de la communauté des développeurs Java dans son évolution. Mais cela permet également d'accroître la qualité du code et de fournir des points d'extension plus facilement utilisables. Enfin, les performances devraient être accrues grâce à ce travail. On note ainsi la proposition d'une équipe externe à Sonatype visant à offrir la parallélisation de builds des projets multimodules, ce qui tend à prouver que le code de Maven 3 est bien plus accessible et lisible que celui de son prédécesseur.

Maven 3 inclut un certain nombre de nouvelles fonctionnalités, ainsi qu'une refonte en profondeur de son cœur. Toutefois, ce dernier doit assurer une compatibilité à 100 % (du moins en théorie) avec les projets Maven 2. En effet, contrairement à la première version, Maven 2 a été largement adopté dans le monde des entreprises et des projets open source. Rendre incompatibles les projets Maven 2 avec l'outil de troisième génération freinerait de façon très importante l'adoption de ce dernier. C'est pourquoi de nombreux tests (environ 600 sont prévus d'ici la version 3.0-GA !) ont été créés afin d'assurer une rétrocompatibilité avec les projets existants.

Techniquement, Maven 3 propose une bibliothèque de compatibilité qui va traduire les appels aux méthodes dépréciées de Maven 2 vers en des appels vers l'API de Maven 3. De cette façon, les plugins écrits pour Maven 2 devraient pouvoir fonctionner également sur Maven 3, en attendant une adaptation officielle de ceux-ci vers la dernière génération de l'outil Maven.

Les dernières versions de NetBeans, d'IntelliJ et du plugin m2eclipse se basent toutes sur Maven 3. Le fait qu'ils arrivent à gérer les projets Maven 2 sans gros problèmes prouve que cette compatibilité ascendante est d'ores et déjà assurée !

On a beaucoup critiqué Maven 2 pour la verbosité de son code XML. Par exemple, le fait de vouloir simplement dire à Maven que notre projet se compile avec Java 5 ou Java 6 nécessite d'écrire de nombreuses lignes, comme on peut le voir ci-dessous :

<plugins>
	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-compiler-plugin</artifactId>
		<version>2.0.2</version>
		<configuration>
			<source>1.6</source>
			<target>1.6</target>
		</configuration>
	</plugin>
</plugins>

De même, l'écriture d'une seule dépendance nécessite l'écriture d'au moins cinq lignes !

Maven 3 sera donc capable de gérer des fichiers POM écrits dans un autre format que le XML. Ainsi, nous pouvons voir ici un exemple de POM de projet utilisant le format YAML (site) (une sorte de format de texte brut, formaté d'une façon particulière) :

groupId: org.twdata.maven
artifactId: maven-yamlpom-plugin
version: 1.0-SNAPSHOT
packaging: maven-plugin
name: YAML POM Plugin
dependencies:
  - { groupId: org.apache.maven, artifactId: maven-plugin-api, version: 2.0 }
  - { groupId: SnakeYAML, artifactId: SnakeYAML, version: 1.1 }
  - { groupId: commons-io, artifactId: commons-io, version: 1.4 }
  - { groupId: dom4j, artifactId: dom4j, version: 1.4 }
  - { groupId: junit, artifactId: junit, version: 3.8.1, scope: test }
  - { groupId: xmlunit, artifactId: xmlunit, version: 1.2, scope: test }
build:
  plugins:
    - artifactId: maven-compiler-plugin
      configuration:
        source: 1.5
        target: 1.5
repositories:
  - id: snakeyaml
    name: SnakeYAML repository
    url: http://snakeyamlrepo.appspot.com/repository

Hormis le XML et le YAML, Maven 3 pourra également supporter des pom écrits en Groovy. On peut imaginer que la liste de ces langages évoluera avec le temps...

Attention, cette fonctionnalité ne devrait pas être incluse nativement dans Maven 3, mais nécessitera l'utilisation d'un plugin particulier. De plus, il est probable que les IDE et les plugins Maven 3 ne supportent que le XML, dans un premier temps du moins. Enfin, bien que cela ne soit pas encore arrêté, il est fort possible que le XML soit privilégié pour stocker toutes les informations (méta-données, pom, etc.) au sein des repositories. Ainsi, le XML devrait rester le langage naturel (la langue maternelle ?) de Maven 3.

Les récentes servlets 3.0 ont introduit la possibilité d'écrire son fichier web.xml (descripteur d'une application web) en plusieurs morceaux, ou fragments. Sur le même principe, Maven 3 va introduire le concept des Mixins. Les Mixins vont nous permettre d'écrire notre fichier pom.xml par composition, c'est-à-dire par fragments, chacun d'eux pouvant alors être déployé comme un artefact séparé dans les repositories de Maven. Ceci nous offrira la possibilité de créer des fragments contenant des informations communes à différents projets, telles que des informations de déploiement sur des serveurs.

Ces mixins vont offrir une forme d'héritage plus complexe, et multiple. C'est Maven qui va retransformer en interne tous ces héritages en un héritage "simple".

Du nouveau également en ce qui concerne le développement des plugins. L'API de Maven devient ainsi plus facilement utilisable, et extensible. Il sera également possible d'étendre un plugin existant, pour compléter son fonctionnement. Ceci évitera donc de réaliser des copier-coller de code de plugin pour reprendre certaines de leurs fonctionnalités !

Autre nouveauté, le cycle de vie de construction de projet proposé par Maven sera lui aussi extensible. En d'autres termes, il sera possible de demander à Maven d'exécuter telle ou telle chose avant ou après n'importe quelle phase de ce cycle de vie.

La troisième génération de l'outil construira un plan de build au démarrage de la construction du projet, contrairement à Maven 2 qui fait cela au fur et à mesure de la construction. Cela signifie qu'un plugin pourra par exemple connaître les opérations qui sont exécutées avant ou même après lui. Le plugin m2eclipse utilise cette fonctionnalité pour déterminer si Eclipse est capable de gérer telle ou telle tâche d'une meilleure façon que Maven (et donc de court-circuiter ce dernier), en particulier lors des compilations incrémentales.

Le module d'accès aux repositories, qui est également en charge de la gestion (et le transfert) des artefacts, a lui aussi été complètement repensé pour Maven 3. C'est désormais Mercury qui sera utilisé pour réaliser ces tâches. Étant donné que l'équipe de Jetty (serveur web léger) a participé activement à son développement, on peut être rassuré quant à la fiabilité de l'outil. C'est donc Mercury qui prendra en charge tous les transferts d'artefacts sur les protocoles HTTP, HTTPS, DAV et DAVS.

Maven Shell est une extension qui permet d'exécuter des commandes Maven dans un environnement de type shell (lignes de commandes). Le principal attrait de cette fonctionnalité est d'accroître les performances de l'outil, en particulier grâce à l'utilisation d'un cache (utilisé surtout par le Reactor). Lors de la conférence Devoxx, Jason Van Zyl a réalisé une démonstration de cet outil. À la première exécution de la commande Maven, le build complet a pris 14 secondes, alors que le deuxième essai n'a pris que 7 secondes !

Cette extension proposera de nouvelles fonctionnalités, de nouvelles options, qui simplifieront les tâches quotidiennes. Enfin, ce shell pourra être supporté par des outils tels qu'Hudson (serveur d'intégration continue), ou encore Nexus (proxy Maven).

Étant donné que Maven 3 n'est pas encore sorti officiellement, on pourrait penser que les outils le supportant ne sont pas encore disponibles. Or, ce n'est pas le cas, comme nous allons voir maintenant. Nous allons ainsi nous intéresser à l'état actuel du support de cette nouvelle version de Maven selon trois types d'outils :

• les IDE (outil de développement) ;
• les serveurs d'intégration continue ;
• les gestionnaires de repositories Maven.

II-I-a. Support au sein des IDE▲

II-I-b. Support de l'intégration continue▲

II-I-3. Support au sein des gestionnaires de repositories▲

La version 3 de Maven paraît plutôt prometteuse, bien que pas vraiment révolutionnaire. Les efforts accomplis sur la réécriture du code du cœur de Maven, ainsi que sur de nombreux tests - visant également à offrir une rétrocompatibilité avec Maven 2 - devraient être accueillis favorablement par la communauté. Cette même communauté devrait être ainsi plus présente sur le développement et les corrections du noyau de l'outil, et non plus seulement se limiter aux plugins Maven.

On regrettera toutefois le manque d'informations relatives à cet outil, car hormis la présentation de Jason Van Zyl à la conférence Devoxx en novembre, ainsi que quelques-uns de ses billets sur le blog de Sonatype, peu d'informations vraiment officielles sont visibles.

Vous pouvez d'ores et déjà télécharger la version alpha de Maven 3 sur le site officiel de Maven.

• Site de Maven
• Site de téléchargement de Maven
• Blog de Sonatype
• Comparatif des outils de builds Java
• Interview d'Arnaud Héritier et Nicolas de Loof à propos de leur livre sur Maven (un chapitre y est consacré à Maven 3).
• Présentation de Maven 3 par Jason Van Zyl
• Blog de Sonatype, "Maven 3.x: Paving the desires lines", 1^re partie, 2^e partie
• Release notes complète de Maven 3.0

Merci à Baptiste Wicht pour ses retours, ainsi qu'à Wachter pour sa relecture minutieuse.