I. Des fourmis ?▲
Si vous faites partie de la grande majorité de développeurs Java qui utilisent Maven, et que vous n'avez jamais entendu parler d'Ant, il s'agit en fait d'un outil de build au fonctionnement radicalement différent.
Inspiré de make, Ant repose sur la notion de cibles (target) qui peuvent être invoquées, et qui elles-mêmes exécutent des tâches (task). Les cibles ont des relations de dépendances entre elles, on peut donc imaginer une cible package qui dépendrait d'une autre cible compile. Dans le monde Maven, on exécute une série de phases dont l'ordre est prédéfini. Le point commun entre les deux, c'est qu'ils reposent sur du XML :
<project
name
=
"MyProject"
default
=
"package"
basedir
=
"."
>
<target
name
=
"compile"
description
=
"compile the source"
>
<!-- insert tasks here -->
</target>
<target
name
=
"package"
description
=
"create the jar"
depends
=
"compile"
>
<!-- insert tasks here -->
</target>
<target
name
=
"clean"
description
=
"clean up"
>
<!-- insert tasks here -->
</target>
</project>
Dans l'exemple ci-dessus, en plus des cibles compile et package (dont j'ai emprunté les noms à Maven), on trouve une cible clean (convention empruntée à make par la communauté Ant, reprise par d'autres outils comme Maven). Cette cible nécessite d'être invoquée explicitement, tout comme il est possible d'invoquer un goal particulier avec Maven.
ant clean
mvn clean:clean
L'avantage pour Maven d'avoir des phases prédéfinies est de garantir à un utilisateur connaissant l'outil de savoir construire un projet "mavenisé" sans connaitre les spécificités du projet :
mvn package
Avec Ant, il faut connaitre le contenu du fichier build.xml pour savoir comment construire un projet, et où trouver le(s) livrable(s) ensuite.
II. Poison Ivy▲
Une autre force de Maven, c'est son gestionnaire de dépendances qui manque cruellement dans Ant. Il est d'ailleurs courant d'avoir un dossier lib/ contenant des JAR versionnés avec les sources !
Ivy est un gestionnaire de dépendances compatible avec les dépôts Maven, il est utilisable de façon indépendante pour n'importe quel usage (c'est extensible). Mais Ivy, c'est aussi un sous-projet d'Ant, et un ensemble de tâches prêtes à l'emploi pour gérer les dépendances de projets Ant. C'est d'ailleurs un gestionnaire de dépendances qui offre bien plus de possibilités que celui de Maven (Aether).
Ivy est pas mal utilisé dans l'écosystème Java, citons :
- Groovy Grapes ;
- Grails ;
- Play! Framework ;
- SBT (lui-même utilisé par Play! 2).
Assez parlé d'Ivy, il s'agit tout de même d'un article sur EasyAnt.
III. Des fourmis… faciles ?▲
EasyAnt donc vient s'ajouter aux côtés d'Ivy à la liste des sous-projets Ant, mais en fait, en quoi ça consiste ?
III-A. Un cycle de vie▲
Alors qu'avec Ant il faut tout faire manuellement, et le refaire à chaque projet, EasyAnt apporte des conventions à la manière de Maven, par-dessus Ant. L'équivalent des phases Maven (compile, test, package…) se présente sous la forme d'extention-points apparus dans Ant 1.8.
On peut les voir comme des cibles abstraites auxquelles il est possible de rattacher d'autres cibles concrètes (avec des tâches). EasyAnt standardise une suite de points d'extensions (compile, test, package…) auxquels des cibles sont greffées, un peu comme les goals Maven qui peuvent être attachés à des phases.
III-B. Un gestionnaire de dépendances▲
Le gestionnaire de dépendances d'EasyAnt est (roulement de tambour…) Ivy. Sauf qu'au lieu de masquer l'utilisation d'Ivy, EasyAnt va plutôt s'intégrer dedans. Un projet utilisant Ant+Ivy pourra donc migrer vers EasyAnt sans rien changer dans sa gestion des dépendances.
La configuration d'Ivy se faisant (encore !) en XML, EasyAnt s'intègre via des balises supplémentaires déclarées dans un namespace http://www.easyant.org. Un projet contient un fichier module.ivy comparable au pom.xml de Maven :
<ivy-module
version
=
"2.0"
xmlns
:
ea
=
"http://www.easyant.org"
>
<info
organisation
=
"com.acme"
module
=
"MyProject"
status
=
"integration"
>
<
ea
:
build
organisation
=
"org.apache.easyant.buildtypes"
module
=
"build-std-java"
revision
=
"0.9"
/>
</info>
<configurations>
<conf
name
=
"default"
/>
<conf
name
=
"test"
/>
</configurations>
<publications>
<artifact
type
=
"jar"
/>
</publications>
<dependencies>
<dependency
org
=
"junit"
name
=
"junit"
rev
=
"4.7"
conf
=
"test->default"
/>
</dependencies>
</ivy-module>
La balise ea:build indique à EasyAnt que l'on souhaite construire un jar (via le plugin build-std-java).
III-C. Un système extensible▲
EasyAnt, qui apporte des conventions similaires à celles de Maven (et souvent compatibles, eg. src/main/java) repose également sur des plugins. EasyAnt ne sera donc qu'un orchestrateur qui exécutera les cibles des plugins qui auront été associées aux points d'extensions concernés.
La différence notable avec Maven, c'est qu'il n'est pas nécessaire d'écrire un plugin pour effectuer une tâche qui ne serait supportée par aucun plugin. Ant étant supporté nativement, il est possible d'ajouter ses propres cibles dans un fichier module.ant à la racine du projet. Une migration d'un projet Ant ayant des cibles utilitaires peut donc se faire sans douleur. On dispose d'une part de conventions de build, et d'autre part d'une facilité de personnalisation.
Petite note personnelle, l'écriture d'une tâche Ant est beaucoup plus simple à mettre en œuvre que l'écriture d'un plugin Maven. J'insiste, c'est beaucoup plus simple. Le ticket d'entrée d'EasyAnt par rapport à Maven sur le terrain des plugins est donc probablement bien moins élevé.
IV. Conclusion▲
EasyAnt est donc le nouveau challenger de l'univers du build. Il vient se frotter à Maven, Gradle et les autres (sauf Ant) en tirant parti de briques existantes et matures.
Vous doutez de la maturité d'Ant et Ivy ? Je vous invite à lire la documentation d'Ivy pour y trouver tout ce que Maven ne sait pas faire (au hasard, les exclusions globales). Quant à Ant, beaucoup de produits fournissent un support d'Ant (eg. Tomcat) et il s'intègre à beaucoup d'autres outils de build :
- Maven ;
- Gradle ;
- Gant ;
- Buildr ;
- JRuby Rake.
EasyAnt est un projet encore jeune, qui peut paraître insignifiant face à Maven et sa pléthore de plugins. Mais EasyAnt profite de tout l'écosystème existant d'Ant pour pallier son manque de plugins. Si vous comptez migrer d'Ant ou Ant+Ivy vers Maven, EasyAnt sera peut-être plus adapté et la solution à privilégier. Si votre projet se heurte fréquemment aux limitations de Maven, la migration vers EasyAnt pourra se faire sans trop de difficultés grâce aux conventions partagées par les deux outils.
Pour s'imposer, je pense qu'EasyAnt devra rattraper son retard en termes d'outillage et de documentation, même si Ivy propose déjà une intégration Eclipse. L'interopérabilité d'Ivy avec Maven est cependant un très bon point de départ. Pour en savoir plus, un tutoriel est paru sur le blog d'EasyAnt, et d'autres arriveront.
V. Remerciements▲
Cet article a été publié avec l'aimable autorisation de Dridi Boukelmoune. L'article original (C'est l'orgie chez les fourmis) peut être vu sur le blog/site de Zenika.
Nous tenons à remercier Claude Leloup pour sa relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.