JAVA 2 - Librairie Eyrolles

© Groupe Eyrolles, 2003,
ISBN : 2-212-11194-0

© Groupe Eyrolles, 2003
2
Environnement de
développement CVS et Ant
CVS | Ant | task | buildfile / makefile
SOMMAIRE
B Gestion du code source avec
CVS
B Configuration de Ant
B Personnalisation de Ant
MOTS-CLÉS
B CVS
B Ant
B task
B build-file / makefile
F
Le travail en équipe, le respect de chartes de développement, les outils de gestion
de projet sont autant de points constituant un environnement de développement.
La méthodologie utilisée, elle aussi, influe sur la façon de travailler et donc sur les
structures et procédures à mettre en place. Les outils exposés par la suite sont la
base du travail en équipe et visent à former un ensemble cohérent et facilitant la
productivité.
Java

Les Cahiers du Programmeur Java (2)
© Groupe Eyrolles, 2003
20
Le tableau suivant plante le décor commenté dans la suite de ce chapitre. La
justification du choix du serveur d’applications ayant été faite précédemment,
on se concentrera sur les autres facettes des choix par la suite.
Gestionnaire de code source : CVS
BlueWeb utilise depuis de nombreuses années CVS comme outil de gestion des
sources et de contrôle de versions, donc ce nouveau projet va naturellement se
voir offrir son espace réservé sur le serveur CVS.
Les développeurs auront l’esprit libre pour travailler, un outil éprouvé se char-
gera de pallier d’éventuelles « bêtises » rendant toujours possible le retour en
arrière vers une version précédente, tandis que le responsable qualité aura tou-
jours la possibilité de restaurer un environnement « labellisé ». La gratuité de
l’outil nous amène à nous demander pourquoi s’en priver… On peut noter que
tout autre gestionnaire de code source (Microsoft Visual Source Safe, Rational
Clearcase, Continuus, etc.) aurait pu être utilisé. CVS est utilisé avec Ant
notamment au chapitre 7 consacré à l’audit du code.
Production des versions : Ant
Le responsable qualité du projet, Michel, alarmé par ses lectures tient à être le
plus détaché possible des outils de production fournis avec les environnements
de développement et à pouvoir utiliser la puissance d’une machine neutre pour
procéder à des builds nocturnes.
Il décide donc d’utiliser sa machine comme machine de référence, pour lancer
des tâches répétitives durant la nuit. L’installation est minime (un JRE + l’ins-
tallation de Ant et quelques librairies), ne coûte pas cher à la société, ne le per-
turbe pas durant son travail (car Michel dort la nuit…) et doit permettre de
déceler très vite différents problèmes (problèmes de compilation, de tests uni-
taires non conformes, qualité). Bien entendu, cet outil sera utilisé avec le serveur
de fichiers sources (CVS) afin de pouvoir produire à la demande une version
labellisée ou encore opérer de la mise en forme sur tout le contenu du référentiel
de sources.
En fait, au niveau du choix de cet outil, BlueWeb n’a guère d’alternatives car si
tous les environnements de développement du marché ( JBuilder, Forté,
Netbeans, Eclipse, etc.) proposent des fonctions de compilation des sources
(ainsi qu’une interaction avec les référentiels de code source), ils se révèlent
Gestionnaire de code
source Outil de make Serveur d’applications
CVS Ant Ensemble intégré JBoss +
Tomcat
OUTIL CVS
CVS est lui aussi un produit Open Source, qui pos-
sède des antécédents tels que la question de son
adéquation avec les besoins de BlueWeb ne se
pose pas. C’est la Rolls des outils de gestion de
configuration, car il est gratuit, performant, stable
et relativement simple à installer. De plus, son
adminsitration est réduite au minimum. Utiliser ce
produit c’est choisir en toute sérennité une valeur
sûre. On peut rappeler à titre anecdotique que des
projets tels que le noyau Linux, le serveur Web
Apache et bien d’autres sont gérés et développés
par des centaines de développeurs sur la planète
en utilisant cet outil.
B http://www.cvshome.org/
ALTERNATIVES Continuus et ClearCase
Ces deux produits sont sûrement les plus aboutis
en la matière, seulement leur coût (prix de la
licence) et le niveau de formation requis avant uti-
lisation réservent leur utilisation à des entreprises
fortunées. Par ailleurs, il faut signaler qu’il est
nécessaire de dédier environ 1 personne sur 10
développeurs pour la seule administration de ces
produits, ce qui a évidemment un coût non négli-
geable (quand il est possible de l’envisager).
ALLER PLUS LOIN
Pourquoi une machine de production ?
Il est indispensable de passer outre les problèmes
de
classpath et de faire en sorte que les livra-
bles (classes Java ou fichiers Java) se comportent
correctement dans un environnement « sain ».
C’est pour cela qu’une machine doit être dédiée à
la production et que celle-ci ne peut se faire sur le
poste de l’un des développeurs du projet. La seule
contrainte est d’avoir une JVM installée et un Ant
proprement configuré. Puis lancer l’exécution du
makefile…

2 – Environnement de développement CVS et Ant
© Groupe Eyrolles, 2003 21
insuffisants car ils ne couvrent qu’une faible partie des besoins en matière de
production des versions :
• interaction avec le serveur CVS ;
• compilation du code ;
• packaging (création d’archives au format jar, etc.) ;
• exécution des tests unitaires ;
• génération de documentation ;
• instrumentation des fichiers sources (c’est-à-dire transformation de ceux-ci
par l’intervention d’un outil) ;
• intégration d’outils tiers (génération automatique de code, génération
d’indicateurs).
Bref, la concurrence sur ce marché est très limitée et Ant s’avère être l’outil stan-
dard dans le monde Java, même si l’on doit reconnaître que les utilisateurs de
l’outil Unix make doivent pouvoir arriver aux mêmes fonctionnalités.
Ant – Vocabulaire de base
La compréhension de l’outil nécessite seulement deux mots même si la maîtrise
réelle du produit réclame un peu plus de travail, mais le jeu en vaut la chan-
delle…
• Task (tâche) : une tâche est au sein d’un makefile l’équivalent d’une instruc-
tion dans un langage de programmation, c’est-à-dire un objet servant à
accomplir une fonction bien spécifique sur éventuellement un certain nom-
bre de paramètres d’entrée (nom du répertoire contenant les classes) et
entraînant un certain résultat (fichier
.jar ). Par exemple, la tâche copy per-
met de copier un fichier (ou un ensemble de fichiers), la tâche
jar permet de
créer un fichier jar, etc.
• Target (cible) : une target est un point d’entrée dans un makefile (donc
caractérisé par son nom : build, doc, all) et vise à accomplir une des étapes
d’un processus de production.
De l’utilisation de la variable CLASSPATH
L’aparté dédié aux machines de production permet d’aborder un problème épineux lié au développe-
ment en Java : l’utilisation de la variable d’environnement
CLASSPATH . Cette variable a pour rôle de
délimiter au sein d’une variable toutes les bibliothèques (
.zip ou .jar ) et tous les chemins d’accès
aux fichiers
.class . Une mauvaise maîtrise de cette variable entraîne de nombreuses questions sur
les forums mais le risque le plus grand provient d’une maîtrise partielle des concepts liés à cette
variable. En effet, vous ne devez jamais supposer quoi que ce soit sur le «CLASSPATH» de la
machine sur laquelle s’exécute votre application. Il vous revient de packager votre application cor-
rectement pour qu’elle puisse être autonome et surtout sans conséquence pour l’environnement de
votre client. Pour cela, Ant ou un script (shell sous Unix ou batch sous DOS) seront vos meilleures
armes. Un bon programmeur Java n’utilise pas la variable d’environnement
CLASSPATH !
VOCABULAIRE Nightly builds
Cette expression provient du jargon du mouve-
ment lié à l’Extreme Programming et notamment
aux idées « d’intégration perpétuelle » (pour con-
tinuous integration dans le vocabulaire original
anglais). Les buts sont multiples mais ils permet-
tent surtout de :
• tester le code entreposé dans le serveur CVS ;
• générer des versions du produit sans interven-
tion humaine ;
• appliquer divers outils sur l’ensemble des sour-
ces du projet de manière à traquer des bugs de
non-régression (tests unitaires), et tester la con-
formité du code avec la charte de codage
interne.
RAPPEL Ant
Ant est un outil de make, c’est-à-dire d’abord des-
tiné à gérer la compilation de code source Java et
la production de fichiers
.class (bytecode). Cet
outil est entièrement écrit en Java et utilise des
makefiles XML (fichiers
build.xml ).

Les Cahiers du Programmeur Java (2)
© Groupe Eyrolles, 2003
22
Par exemple, on pourrait décider de créer un makefile compilant les sources et
d’appeler cette étape du processus global de production par compile. Une autre
étape pourrait être la destruction du résultat d’une compilation appelée
clean .
Notons qu’un projet contient des cibles (targets) faisant appel à différentes
tâches éventuellement interdépendantes. Voici ci-dessous un exemple de make-
file pouvant répondre à ce besoin.
Adapter Ant à ses besoins
L’objet de ce livre n’est pas d’aborder Ant de manière exhaustive (est-ce
possible ?). On ne tient pas à évoquer toutes les tâches prédéfinies (
built-in tasks )
et encore moins à évoquer tous les contextes d’utilisation possibles, mais étant
donné l’importance de l’outil au sein de l’ouvrage, il est nécessaire de s’attarder un
peu sur quelques spécificités de ce produit qui le rendent aussi particulier.
Exemple de makefile
Création d’un projet dénommé « Petit Projet »
dont le répertoire de base (
basedir ) est le
répertoire courant (
. ) et la cible par défaut
(
default ) est compile .
B
<project name="Petit Projet" default="compile" basedir=".">
<!-- ici on positionne des valeurs pour ce build -->
<!-- d'une maniere tres originale on indique que ${src} va
representer le directory src -->
<property name="src" location="src"/>
<property name="build" location="build"/>
<!-- cette cible realise l'init de notre build-file -->
<!-- ici reduite a cree le repertoire pointe par la variable${build}
(valeur build d'apres l'initialisation precedente -->
<target name="init">
<!- creee le repertoire ${build} -->
<mkdir dir="${build}"/>
</target>
<!-- cette cible compile le code source -->
<target name="compile" depends="init"
description="compile le code source requiert l'execution de la
tache init " >
Src
va désigner le répertoire où seront stockés
les fichiers sources. De même « build » désigne
le répertoire créé par la compilation.
B
Ici on peut noter l’utilisation de l’attribut
description permettant de renseigner un uti-
lisateur de l’utilité d’une cible. Remarquez que
ce message n’est affiché que quand l’utilisateur
désire en savoir plus sur votre processus de
construction, c’est-à-dire en tapant
ant –projecthelp .
B
<!-- Compile le code contenu dans: ${src} en deposant les classes dans
: ${build} -->
<javac srcdir="${src}" destdir="${build}"/>
</target>
<!-- un peu de menage pouvant etre utile, cette cible detruit le
repertoire ${build} -->
<!-- donc pour etre sur de repartir de zero il faudra l'invoquer via
un: ant clean -->
<target name="clean"
description="detruit le reperoire de build" >
<!-- Detruit le repertoire ${build} -->
<delete dir="${build}"/>
</target>
</project>