Tutoriel sur les fonctionnalités de l'outil de build EasyAnt

| Dridi Boukelmoune (Zenika) | Zenika |

À l'occasion de la sortie d'Ant 1.9.0, Ivy 2.3.0 et du tout récent EasyAnt, je vous propose de découvrir ce nouvel outil de build qui vient s'ajouter à la liste (déjà bien fournie) des outils existants.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum Commentez .

- Titre : Tutoriel sur les fonctionnalités de l'outil de build EasyAnt

- Auteurs : Dridi Boukelmoune (Zenika), Zenika

- Parution : 20 juin 2013

- Licence : Copyright ® 2013 Dridi Boukelmoune. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Des fourmis ?

- II. Poison Ivy

- III. Des fourmis… faciles ?

- III-A. Un cycle de vie

- III-B. Un gestionnaire de dépendances

- III-C. Un système extensible

- IV. Conclusion

- V. Remerciements

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.