Apache Ant, Installation et exploitation.

27 November 2007 par Antoine Dumeige

Introduction

Ant est un outil de construction d’application intégralement écrit en Java. Il supporte le même type de fonctionnalités que l’ancêtre Make tout en apportant de nouvelles. Enfin, contrairement à ce dernier, Ant étant réalisé en Java, il se comporte de manière identique sur tous les systèmes disposant du machine virtuelle Java, évitant ainsi le long et pénible chemin de croix nécessaire à toute réalisation via Make ou les autotools en cross-platform (surtout quand un système Microsoft fait partie des systèmes visés par l’application).

Contrairement aux principaux outils concurrents du monde Unix, ant utilise une syntaxe basée sur XML pour définir les différentes tâches de construction, ce qui peut rendre la lecture d’un script de build assez hermétique à un novice, mais assure en contrepartie une syntaxe unifiée pour toutes les actions possibles, qu’elles soient natives ou ajoutées via le système de plugins très simple de Ant.

Parlons –en justement de ces plugins. Ant étant ouvert et reposant sur Java, il est très aisé de développer un plugin pour une fonctionnalité donnée (transfert via SSH, compilation d’un langage donné etc…), ce qui permet à Ant d’être très facilement extensible et de couvrir à peu près tous les besoins inhérents au développement d’applications conséquentes : compilation, gestion de version, déploiement, distribution, archivage et j’en passe.

Ant est un outil de plus en plus utilisé, notamment dans le monde Java où la quasi-intégralité des développements conséquents l’utilisent en tant que build system. Ses fonctionnalités ne se limitent cependant pas au monde Java et son fonctionnement identique quelque soit la plateforme lui gagne chaque jour des développeurs de tous les horizons.

Dans ce document, je me propose de vous donner un avant gout de l’utilisation de cet outil très performant en diverses étapes : installation, premier script « HelloWorld », compilation d’un projet Java et enfin, déploiement d’un projet J2EE via la génération d’une archive WAR.

Installation

Tout d’abord, il faut se procurer une version d’Ant. Toutes les versions sont disponibles pour tous les systèmes sur le site officiel de l’outil : http://ant.apache.org/.

Si vous utilisez une IDE telle que NetBeans ou Eclipse, Ant est packagé avec celui-ci, vous pouvez donc sauter le chapitre d’installation.

Je m’intéresserai en particulier à l’installation sur les systèmes Windows, l’installation sous les systèmes *N*X étant très simple via le système de déploiement intégré à la plupart d’entre eux.

Une fois l’archive Ant téléchargée, décompressez là dans votre répertoire d’applications (C:\Programmes Files\, par exemple). Ensuite, il suffit de mettre à jour les variables d’environnement PATH et ANT_HOME et Ant est prêt à être utilisé. Ajoutez au PATH Windows le chemin pointant vers le répertoire bin de votre installation Ant.

Pour tester très simplement votre installation, ouvrez un terminal, et tapez Ant, si vous obtenez un message disant que build.xml n’existe pas, c’est gagné.

Passons maintenant à un peu de pratique.

Hello World

Rien ne vaut un classique Hello World pour se mettre en jambes. Quand vous appelez Ant, celui-ci regarde si un script build.xml est présent dans le répertoire courant, c’est ce fichier qui doit contenir les directives de construction de votre application. Commençons donc par en créer un.

La balise racine de votre fichier build.xml doit toujours être <project>, cette balise devra contenir les différentes tâches de construction liées à votre application. Dans le cas qui nous concerne, nous n’aurons qu’une directive : hello-world, ce qui donne le fichier build.xml suivant :

<?xml version="1.0" encoding="UTF-8"?>

<project default="hello-world">

<target name="hello-world">

<echo message="Hello World !" />

</target>

</project>

Expliquons ce code en détail :

  • La balise <project> définit le début de la liste de tâches de notre projet.
  • Son attribut « default » précise la cible par défaut à appeler si l’utilisateur ne la spécifie pas.
  • La balise « target » définit une nouvelle cible pour notre projet, son nom est « hello-world ».
  • Tout ce qui se trouve entre les balises <target> et </target> est la liste des différentes actions à effectuer pour cette cible, dans notre cas, nous nous contenterons d’afficher « Hello World ! » sur la sortie standard.

L’appel de la commande ant, affichera maintenant les résultats suivants :

Buildfile: Z:\workspace\build.xml

hellow-world:

[echo] Hello World !

BUILD SUCCESSFUL

Total time: 715 milliseconds

Cela fonctionne car « hello-world » est la cible par défaut du fichier. Pour appeler explicitement une cible, il suffit de taper :

ant hello-world

Il est tout à fait possible d’enchainer plusieurs cibles.

 

Propriétés et fichiers de propriétés

Propriétés :

Dans le script précédent, le message à afficher, « Hello World ! » est donné directement dans le script. Pour un simple message, cela ne pose pas de problème particulier, en revanche, il peut être nécessaire de référencer des binaires ou des paths particuliers à un système, de donner des mots de passe etc… Ce qui signifie que tout utilisateur du script devra mettre à jour le fichier build.xml pour pouvoir l’utiliser sur son système. Cette pratique est bien entendu lourde, dangereuse et donc, à proscrire.

Ant nous fournit pour cela la possibilité de définir des propriétés, c'est-à-dire l’association d’une valeur textuelle à une variable. On définit une propriété comme suit :

<property name="variable" value="valeur" />

On appelle une propriété de cette manière :

<echo message="${hw}" />

Notre build.xml devient alors :

<?xml version="1.0" encoding="UTF-8"?>

<project default="hello-world">

<property name="hw" value="Hello World !" />

<target name="hello-world">

<echo message="${hw}" />

</target>

</project>

Le résultat sera strictement équivalent à la première version.

Fichiers de propriétés :

Le problème avec cette syntaxe est sa lourdeur et le fait qu’il faille encore modifier le fichier build.xml pour adapter le script à un environnement donné. Ant rend possible, pour éviter ces problèmes, de définir dans un ou plusieurs fichier annexes toutes les propriétés du projet. Il est alors possible d’utiliser deux syntaxes différentes : celle basée sur XML que je viens de vous présenter, et celle basée sur le standard amené par Sun sur les fichiers .properties. Cette deuxième approche a ma préférence car moins verbeuse, mais là, c’est une question de goûts.

Voici comment appeler un fichier de propriétés :

<property file="build.properties" />

Et voici à quoi ressemblerait le fichier build.properties :

hw=Hello World !

author=Antoine Dumeige

Le fichier build.xml ressemblerait lui à :

<?xml version="1.0" encoding="UTF-8"?>

<project default="hello-world">

<property file=="build.properties" />

<target name="hello-world">

<echo message="${hw}, by ${author}" />

</target>

</project>

Et voila, si Mme Michu souhaite utiliser le script chez elle, elle n’a qu’à mettre à jour le fichier build.properties pour que le tout fonctionne !

 

Compilation et dépendances

Maintenant que nous avons vu comment s’articule un fichier build.xml, il est temps de rentrer dans le cœur du sujet en regardant comment compiler une application Java via Ant. Vous verrez, cela n’a vraiment rien de compliqué !

La balise à utiliser est <javac>, ce qui parait logique puisque c’est le nom du compilateur Java standard sur tous les systèmes. Cette balise devra prendre deux paramètres : srcdir et destdir, les valeurs de ces paramètres auront bien sur été remplies via à un fichier de propriétés.

Le comportement de cette balise est le suivant : tous les fichiers .java de l’arborescence de srcdir seront compilés, et le fichier .class correspondant sera mis dans destdir en gardant l’arborescence originale. Le seul travail à effectuer est de s’assurer que destdir existe bel et bien. Une bonne pratique pour cela est de définir une tâche d’initialisation qui va se charger de la création de destdir. Cette tâche d’initialisation sera indiquée dans les dépendances de la tâche de compilation.

Voilà à quoi ressemble le fichier de propriétés :

builddir=./build/

srcdir=./src/

libdir=./lib/

La tâche d’initialisation quand à elle est très simple :

<target name="init">

<mkdir dir="${builddir}" />

</target>

Il est intéressant de noter qu’Ant ne créera le dossier que s’il n’existe pas encore.

Enfin, la tâche de compilation à proprement parler :

<target name="build" depends="init">

<javac srcdir="${srcdir}"

destdir="${builddir}"/>

</target>

Le paramètre « depends » de la tâche build signifie qu’Ant devra toujours exécuter les tâches y étant mentionnées (séparées par des virgules) avant d’exécuter la tâche courante.

Si votre programme fait appel à des bibliothèques, il est alors nécessaire de les référencer pour que la compilation s’effectue correctement, pour ce faire, il suffit de définir un classpath et de le référencer dans la tâche build. Voici un exemple :

<path id="classpath">

<fileset dir="${libdir}" includes="**/*.jar" />

</path>

Ce script définit simplement un path ayant comme identifiant « classpath », composé d’un ensemble de fichier pris dans libdir ayant pour extension .jar.

Il faut ensuite référencer ce classpath :

<target name="build" depends="init">

<javac srcdir="${srcdir}"

destdir="${builddir}"

classpathref="classpath" mce_href="classpath" />

</target>

Et voila, ça compile.

 

Déploiement J2EE : création d’une archive WAR.

Une fois que vous avez développé et compilé une application J2EE, le plus simple pour la déployer est de générer une archive WAR. Ant dispose d’un procédé dédié à cette tâche.

La balise <war> va donc vous permettre de générer l’archive. Cette balise prend 3 paramètres obligatoires :

  • destfile : le fichier à créer.
  • basedir : le répertoire à partir duquel générer l’archive.
  • webxml : le fichier web.xml à utiliser.

Nous allons donc spécifier des propriétés dans le fichier leur étant dédié pour chacun de ces paramètres, ce qui nous donne :

builddir=./build/

srcdir=./src/

libdir=./lib/

war=./dist/myProject.war

web.xml=./build/web.xml

On ajoutera la cible suivante au fichier build.xml :

<target name="war" depends="init, build">

<war destfile="${war}"

basedir="${builddir}"

webxml="${web.xml}" />

</target>

 

<x

Conclusion

Nous avons donc avec Ant un outil de construction d’application très puissant, portable, aussi complet que possible et extensible. Si la syntaxe des fichiers de build peut déboussoler au premier abord, elle devient très claire après un peu de pratique et permet une réelle flexibilité. J’espère que ce petit tour d’horizon vous aura motivé à utiliser ce puissant outil et à aller plus loin dans sa découverte.

Tags: , ,

13 commentaires pour “Apache Ant, Installation et exploitation.”

  1. Serge dit :

    J’ai essayé de faire un build.xml. Mais j’ai eu un erreur “javac doesn’t support the “mce_href” attribute” sur la ligne du code de l’exemple décrit plus haut:
    [/code]
    "
    [/code]
    A quoi est du cette erreur. Merci.

  2. Antoine Dumeige dit :

    La propriété est href, pas mce_href, il s’agit d’une erreur de frappe.

  3. zaimenergie dit :

    je veux intégrer checkstyle dans le build.xml sais tu comment le faire?

  4. Antoine Dumeige dit :

    Non, désolé, je ne connais pas “checkstyle”, de quoi s’agit-il ?

  5. cappel_f dit :

    Une moulinette de norme pour Java.
    La documentation explique comment l’utiliser avec Ant.
    http://checkstyle.sourceforge.net/anttask.html

  6. samir dit :

    Merci, bonne approche pour introduire ant.
    Après il faut cerner les structures et processus de projets J2EE et automatiser avec ant.
    A quoi sert l’attribut href ?

  7. Fmeg dit :

    MERCI
    je veux installer jonas4.8.6-tomcat5.5.17 sous windows pour la plate forme bonita v3.1 mais le fichier build.xml de ant de ce projet est trés déficile pour cette l’installation Existe-t-il une solution
    Merci d’avance !

  8. Vic dit :

    Merci beaucoup! Ce sont mes premiers pas avec ant et je dois déployer toute mon appli avec un installer et du ant tout automatisé pour pouvoir l’installer sur tous les postes clients, merci pour ce premier pas !

  9. Cac dit :

    Très bonne initiation

  10. astrotouf dit :

    merci beaucoup pour cette introduction fort agréable.
    Je n’ai par contre par compris l’attribut mce_href dans la balise javac.

  11. Matthieu Chatel dit :

    Il faut remplacer l’attribut mce_href par href.
    L’attribut mce_href est un attribut propre au composant javascript tiny mce qui permet entre autre d’avoir une boite d’édition de texte avancé dans une page web.

  12. astrotouf dit :

    ça serait bien d’ajouter du formatage de code dans ton blog. il y a une très bonne extension wordpress :WP-Syntax.

    @+

  13. marcl1 dit :

    Super merci.
    Je n’y connaissais absolument rien et cela m’a ouvert
    bien ds portes.

Laisser un commentaire


two × = 6