Outils de gestion du cycle de vie

des applications

Auteur : Henri Jones

Date : Lundi 13 décembre 2010
Version : 1.0
Outils de gestion du cycle de vie
des applications
avec logiciels libres
(Subversion, Maven, Nexus, Hudson, Sonar)
 Outils de gestion du cycle de vie
des applications

Table des matières

 1 Introduction........................................................................................................................... 8
 1.1 Motivations...................................................................................................................... 8
 2 Cycle de vie........................................................................................................................... 9
 3 Subversion.......................................................................................................................... 10
 3.1 Accès à un dépôt........................................................................................................... 10
 3.2 Organiser son projet pour SVN......................................................................................11
 3.3 Fonctionnement............................................................................................................. 13
 3.4 Travailler avec des branches.........................................................................................13
 4 Maven.................................................................................................................................. 15
 4.1 Projet Object Model (POM)............................................................................................15
 4.2 Structure d'un projet Maven et conventions...................................................................16
 4.3 Gestion des dépendances.............................................................................................16
 4.4 La notion de plugins.......................................................................................................17
 4.5 Cycle de vie de construction..........................................................................................17
 4.6 Héritage de projets et modules......................................................................................18
 4.7 Création d'un archétype.................................................................................................19
 5 Gestion d'un dépôt d'artefacts..........................................................................................21
 5.1 Nexus............................................................................................................................ 21
 5.2 Ajout de son dépôt ........................................................................................................21
 5.3 Ajout d'un nouvel artefact...............................................................................................22
 6 L'intégration continue........................................................................................................24
 6.1 But de l'intégration continue...........................................................................................24
 6.2 Hudson.......................................................................................................................... 24
 7 Analyse de code................................................................................................................. 26
 7.1 Sonar............................................................................................................................. 26
 8 Conclusion.......................................................................................................................... 27
 9 Bibliographie....................................................................................................................... 28

II
 Outils de gestion du cycle de vie
des applications

Remerciements
Toute   l'équipe   des   projets   Hudson   (Jenkins)   et   Nexus   pour   l'excellente   documentation 
proposée.

Ainsi que de manière générale, toute la communauté open source  qui assure la maintenance, 
distribution des remarquables outils utilisés pour la rédactions de ce rapport.

III
 Outils de gestion du cycle de vie
des applications

Résumé
Les différentes problématiques présentes lors de la gestion d'un projet logiciel peuvent être 
résolues à l'aide de logiciels open sources. Chaque outil présenté a une fonction spécifique, 
mais l'ensemble de ces logiciels permet de gérer de manière la plus efficace possible le cycle 
de vie d'une application.

Apache   Maven  permet   entre  autre  de   gérer   la  structure  et   la   construction   du  projet.   Il  est 
possible à l'aide du gestionnaire de dépôt central Maven ou privé tel que Nexus de gérer toutes 
les dépendances et librairies externes. Tout le code étant géré par un SCM tel que Subversion 
permet à plusieurs développeurs de travailler de manière concurrente.

L'intégration est quand à elle effectuée à l'aide du serveur Hudson. La vérification de la qualité 
est effectué à l'aide du logiciel Sonar.

La solution proposée est parfaitement générique et peut être réalisé à l'aide d'autres logiciels 
présents   sur   le   marché.   Cette   solution,   moyennant   quelques   adaptation   est   applicable   à 
n'importe quel projet de petite ou de grande envergure.

Abstract
A lot of problematics can be resolved with open source softwares. Each software has a specific 
function, but the whole of these is used to manage efficiently the software life cycle.

Apache Maven deals with the structure and the compilation of the project. It's possible with the 
central Maven or a private repository like Nexus to manage all the dependencies or third party 
code. All the code is managed with a Software Configuration Manager like Subversion. With 
this approach all the dev team can work simultaneously.

The continuous integration is performed with the Hudson server. The quality of the code is 
checked with Sonar.

The proposed solution is generic and can be perform with others software on the market. It's 
possible to implements this solution with small or big projects.

IV
 Outils de gestion du cycle de vie
des applications

Moyens mis en place
Les moyens mis en place afin de tester les solutions sont l'installation d'un serveur personnel. 
Les logiciels qui ont été installés est testés sont les suivants :

• Serveur Web Apache 2
• Serveur d'application Java Glassfish 3
• Serveur SVN avec module Apache
• Serveur d'intégration Hudson 
• Dépôt d'artefacts avec Nexus 

Également sur une machine locale

• Client SVN
• Maven 2
• NetBeans 6.9
• Sonar pour l'analyse de code

La plupart des fonctionnalités de ces logiciels ont été testées, entre autre :

• Configuration du serveur SVN avec plusieurs utilisateurs et restrictions (en production 
pour les laboratoires et projets)
• Configuration de différents  triggers   (Nightly  build1,  à chaque  commit  de code source, 
etc.) sous Hudson pour lancer la construction d'un projet et le déploiement.  Les tests 
sont lancés à chaque compilation. 
• Configuration de son propre dépôt d'artefacts
• Création des divers projets Maven et configuration des goals
• Création d'un archétype Maven pour les laboratoires et projets.
• Déploiement d'une archive JAR depuis Maven sous Nexus

1 Également appelé Neutral Build 

V
 1 Introduction
Ce rapport présente différents concepts afin de gérer au mieux la gestion du cycle de vie des 
applications.   Par   le   terme   « application »,   nous   entendons   la   gestion   complète   d'un   projet 
conséquent (plusieurs milliers de fichiers) qui peut devenir rapidement fastidieuse celle­ci n'est pas 
faite correctement.

Le cycle de vie d'une application passe par différentes phases importantes comme par exemple la 
construction, l'exécution des tests, le déploiement, l'intégration, la livraison, etc.

Ce rapport se veut indépendant du modèle de cycle de vie utilisé (Cycle en V, Itératif) et de toute 
méthode   de   développement.   Théoriquement,   les   concepts   présentés   peuvent   s'appliquer   à 
n'importe quel projet. Néanmoins nous nous focaliserons sur les applications Java/Java EE qui 
sont à l'heure actuelle très utilisées en entreprise.

Il existe une multitude d'outils sur le marché permettant de gérer les différentes phases d'un projet. 
Nous  ne présentons dans ce rapport que les logiciels open sources.

Dans le Chapitre 2 nous aborderons la problématique du cycle de vie et présentons l'architecture 
utilisée. Le Chapitre  3  quant à lui aborde la problématique du travail concurrent sur un projet et 
présente   le   logiciel   Subversion.   Dans   le   Chapitre  4  consacré   à   Maven,   nous   abordons   la 
problématique   de   la   construction   du   projet.   Nous   expliquons   également   comment   à   l'aide   de 
Maven faire communiquer nos différents serveur logiciels. Le Chapitre 5 réponds à la question de 
la   gestion   des   dépendances   et   le   Chapitre  6  sur   l'intégration   continue   avec   Hudson.   Enfin,   le 
Chapitre 7 aborde la question de l'analyse de code.

 1.1  Motivations

Imaginons une équipe de 50 développeurs travaillant sur un projet contenant différents modules. 
Certains   de   ces   modules   sont   dépendants   entre   eux   et   dépendants     de   librairies   externes. 
Comment alors gérer les différentes versions et dépendances ?

Les développeurs travaillent en parallèle sur différents fichiers. Une livraison est prévue dans 2 
semaines et il faut figer l'ajout de nouvelles fonctionnalités pour se consacrer aux bugs. Comment 
ne pas retarder une autre équipe qui elle, continue à ajouter de nouvelles fonctionnalités pour une 
prochaine livraison ?

Des tests ont été écrit pour chaque module. Comment être sûr que chaque développeur exécute 
les tests après les modifications effectuées sur le code ?.  Admettons que tout les modules ont été 
testés, comment garantir la bonne fonctionnalité une fois les modules réunis ?

Toutes ces questions seront répondues à l'aide de ce document.

1
 2 Cycle de vie
Le  cycle de  vie ou  cycle  de  développement  est  un élément   important   dans la  réalisation  d'un 
logiciel. En effet, lors de projets conséquents, il faudra gérer un maximum d'étapes pour arriver à 
une effectuer une livraison à temps où le logiciel sera conforme aux spécifications, exempt de bug 
(dans la mesure du possible...).

Il faudra répondre aux critères suivants :

• Les   développeurs   devront   pouvoir   travailler   sur   une   même   portion   de   code   sans 
s'interbloquer
• Il faudra gérer de façon efficace les dépendances ainsi que leurs versions
• Des   tests   devront   être   régulièrement   lancés   afin   de   vérifier   que   le   logiciel   fonctionne 
toujours après une mise à jour
• Il faudra vérifier que le code produit par les développeurs soit conforme aux conventions 
établies par l'entreprise ou le client

Figure 1: Architecture  étudiée

Sur la Figure 1 Maven est représenté comme un système complet (éventuellement installé sur des 
machines   différentes)   permettant   d'agir   sur   les   différents   composants   intervenant   dans 
l'architecture.

Dans   les   chapitres   suivants,   nous   allons   explorer   les   différents   composants   intervenants   dans 
cette architecture.

2
 3 Subversion
Subversion   est   un  SCM  (Source   Configuration   Manager)   ou   plus   précisément   un   outil   qui   va 
permettre   de   suivre   les   différentes   modifications   au   niveau   du   code   logiciel.   Il   permet   ainsi   à 
plusieurs développeurs de travailler sur une même portion de code.

Par   abus   de   langage   il   est   souvent   abrégé  SVN,   mais   en   réalité  svn  (en   minuscule)  est   le 
protocole utilisé pour communiquer avec Subversion.

SVN est très utilisé dans le monde professionnel, mais pas toujours de façon appropriée. Nous 
verrons   de   ce  chapitre   comment   utiliser   au   mieu   toute   la   puissance   d'un   bon   gestionnaire   de 
versions.

 3.1  Accès à un dépôt

Subversion à l'inverse d'autres SCM comme Git 2, ou Mercurial3  est un gestionnaire de versions 

centralisé. A l'inverse, on parle de gestion décentralisée.

Le dépôt central de Subversion est généralement situé sur un serveur distant. Mais on peut très 
bien imaginer installer subversion sur une machine locale.

L'accès au dépôt se fait en se connectant sur l'URL du dépôt (port 3690). Par exemple : 

svn://code.google.com/p/projet

Dans le cas où le port 3690 serait bloqué par un pare­feu, il est possible de configurer le serveur 
Subversion   pour  fonctionner  avec  un  serveur  Apache  sous le  port  80 (Ou  tout  autre port).  La 
configuration   à   l'aide   d'Apache   s'effectue   à   l'aide   du   module  svn_dav.  Plus   d'informations 
concernant la mise en service de SVN avec Apache sont disponibles au Chapitre 6 de [1]

Par exemple pour le SVN suivant, Apache et Subversion ont été configurés pour écouter sur le 
port 8080.

http://svn.exemple.ch:8080/projets

D'autres protocoles que HTTP et SVN sont possibles pour accéder à un dépôt. Citons par exemple 
SVN+SSH qui permet d'avoir un accès sécurisé au code source.

Il   existe   une   multitude   de   clients   permettant   de   se   connecter   à   un   serveur  SVN.   Citons   par 
exemple Tortoise SVN4 qui s'intègre directement à l'explorateur Windows ou RapidSVN qui permet 
de gérer ses copies locales de manière graphique.

2 http://mercurial.selenic.com
3 http://git­scm.com
4 http://tortoisesvn.tigris.org/

3
Il existe énormément de documentation pour installer et gérer son propre dépôt. Nous conseillons 
particulièrement  les ouvrages  [1]  et  [2]  qui expliquent  pas à pas comment installer  son propre 
serveur SVN.

 3.2  Organiser son projet pour SVN

Structurer son arborescence de dossiers est très important pour Subversion. Il est nécessaire d'y 
réfléchir bien avant avant de commencer à remplir son serveur de code source. Le déplacement 
de dossiers est bien souvent source d'erreur et de conflit dans un gestionnaire de version.

Nous donnerons dans ce chapitre quelques conseils permettant d'organiser au mieu son dépôt.

/
/trunk
/src
/doc
/branches
/tags

Architecture 3.1: Arborescence recommandée pour un dépôt SVN

Le dossier principal contient 3 dossiers.

Le   dossier  trunk  pour   le   « tronc »  contient   le   code   source   du  projet  (dossier  src)  ainsi   que   la 
documentation (dossier doc). Par convention le code source se trouvant dans le trunk devra être 
compilable et passer tout les tests. Nous reviendrons sur cet aspect dans le Chapitre 3.4 Travailler
avec des branches.

L'organisation   du   dossier  src  est   bien   entendue  laissée  à   la   charge   des   développeurs,   mais 
néanmoins   une   bonne   organisation   de   ce   dossier   permettra   de   gagner  du   temps   lors   de   la 
recherche d'un fichier, surtout lorsque le projet devient conséquent.

/src
\codebase
\web
\db
\gui
\module1
\module2
\lib
\sandbox
\...

Architecture 3.2: Exemple d'organisation du dossier src pour un dépôt SVN

Le dossier codebase contient l'essentiel du code source créé par l'entreprise. Il doit être exempt de 
toute librairie ou code tierce­partie.

4
Le dossier  lib  contient les différentes librairies utilisées dans le projet. Nous verrons au  Chapitre 
4.3 Gestion des dépendances que les librairies ne seront généralement pas stockées dans le SVN 
mais plutôt sur un dépôt privé d'artifacts.

Pour résumer, le SVN devra contenir les fichiers suivants :

• Fichiers sources
• Fichiers sources des tests
• Fichiers de build (build.xml, pom.xml, MakeFile, etc..) et configuration.
• Documentation

Par contre il ne devra pas contenir les fichiers suivants :

• Fichiers compilés (.class, .exe, ..)
• Documentation générée automatiquement (JavaDoc, Doxygen)
• Fichiers ou dossiers spécifiques à la configuration d'un IDE (.project, .settings, ...)

Bref tout ce qui est possible d'obtenir, en ayant le code source à disposition ne doit pas figurer 
dans le dépôt.

Les informations de ce chapitre sont largement inspirées de [3] et du Chapitre 7 : Organiser votre 
dépôt de [2]

 3.3  Fonctionnement

Le fonctionnement de subversion est le suivant :

• Les développeurs effectuent un  checkout  du code, c'est à dire qu'ils créent une copie du 

code source sur leur machine
• Le   développeurs   effectuent   les   modifications   sur   le   code   puis   effectuent   un  commit  en 
indiquant un message de log. Les modifications sont propagés sur le dépôt central.
• Les développeurs résolvent éventuellement les conflits qui peuvent apparaître. 
• Les développeurs effectuent un update afin de mettre leur copie à jour.

 3.4  Travailler avec des branches

Sous subversion une branche est une séparation logique du système de gestion de versions. Un 
même fichier peut exister indépendamment dans plusieurs branches et peut y subir différentes 
modification. Subversion garde une trace des fichiers copiés afin de permettre ensuite d'effectuer 
une fusion sur ces fichiers.

Concrètement les branches sont utilisées pour modifier du code existant sans forcément être sûr 
de l'impact sur le reste du projet. Comme dit précédemment tout le code se situant dans /trunk
doit être compilable à tout moment.

Des branches seront crées pour :

5
 • Effectuer du refactoring de code
• Figer l'ajout de nouvelles fonctionnalités pour une livraison. 
• Corriger des bugs

La création d'une nouvelle branche s'effectue simplement en créant une copie du  trunk  (ou un 

sous ensemble) dans le dossier /branches du SVN. Notons que quelque soit la taille du dossier du 
trunk,  la   copie   est   très   extrêmement   rapide.   En   effet,   Subversion   se   souvient   uniquement   du 
numéro de révision où a été fait la copie  et n'enregistre que les modifications post­copie.

La création d'une branche peut s'effectuer avec la commande suivante :

svn cp http://svn.exemple.ch:8080/devs/trunk
http://svn.exemple.ch:8080/devs/branches/livraison1

Une fois les modifications effectuées dans la branche, il sera peut être nécessaire d'intégrer ces 
modifications au trunk. Pour cela, on utilise la commande svn merge.

Figure 3.1: Création et fusion d'une branche

La  durée de  vie d'un  branche est  éphémère.  Si  le  but  est   de  créer  une image  du code  à un 
moment   précis   (Par   exemple   pour   la   livraison   d'une  release),   SVN   met   à   disposition   un 
mécanisme qui s'appelle les tags permettant comme leur nom l'indique de marquer le code source 
à un moment précis.

Le lecteur qui sera intéressé à avoir plus d'informations pour utilisé SVN se verra recommander 
l'ouvrage [2] 

6
 4 Maven
Maven est un logiciel écrit en Java, donc multi­platforme. Maven est un projet soutenu et maintenu 
par la fondation Apache5. 

Il   permet   de   gérer   efficacement   les   phases   de   construction   et   de   déploiement   d'un   projet.   La 
gestion avancée des dépendances est également ce qui fait la force de Maven.

Maven   permet   d'effectuer   beaucoup   de   choses.   En   revanche,   sa   configuration   est   assez 

fastidieuse et assez longue. Celle­ci s'effectue principalement  à deux endroits : dans un fichier 
.settings.xml situé dans le dossier de l'utilisateur et dans un fichier pom.xml. Le fichier settings.xml 
est spécifique à un utilisateur et défini ses préférences alors que le fichier pom.xml est spécifique à 
chaque projet.

Par contre, une fois la configuration de Maven maîtrisée, il fait gagner un temps considérable au 
développeur ainsi qu'à l'équipe de développement toute entière.

 4.1  Projet Object Model (POM)

Le POM pour  Projet Object Model est  un fichier XML figurant  à la racine du projet.  Le fichier 

pom.xml  décrit   les   différentes   informations   permettant   de   construire   le   projet   (et   bien   d'autres 
choses qui seront détaillées dans les chapitres suivants)

Les   utilisateurs   de   Ant6  verront   une   similarité   avec   la   fameux   fichier  build.xml  qui   permet   de 
construire le projet Ant.
Chaque fichier POM contient une en­tête qui contiendra au minimum les informations se trouvant 
dans le Listing 1.

<groupId>ch.heigvd.app</groupId>
<artifactId>Geos</artifactId>
<version>1.0-SNAPSHOT</version>
Listing 1: En­tête d'un fichier POM

Ces informations permettent d'identifier de manière univoque le projet. La première balise indique 
le groupe ou l'entreprise ayant réalisé l'application, la deuxième le nom du projet et la troisième la 
version.

Dans   la   Terminologie   Maven,   une   version  SNAPSHOT  est   une   version   en   cours   de 
développement. Nous reviendrons sur cet aspect un peu plus tard.

5 http://www.apache.org
6 http://ant.apache.org/

7
 4.2  Structure d'un projet Maven et conventions

Un des intérêt de Maven est de simplifier la phase de construction d'un projet. Un des principal 
défaut   de   Ant   est   qu'il   faut   pour   chaque   projet   recréer   un   fichier  build.xml  qui   contiendra 
l'emplacement   des   différents   fichiers   sources,   l'emplacement   des   futurs  fichiers   compilés, 
l'emplacement de l'archive jar, etc. A quelques exceptions près, ce fichier  sera identique pour tous 
les projets, ce qui implique beaucoup de copier­collé pour recréer un fichier de configuration.

Maven  fait  en  sorte de  ne pas  avoir  cette  approche  et  par  du  principe  que  chaque  projet   est 
structuré de la même manière. Cette approche peut être un peu trop contraignante, mais en réalité 
tout les projets suivent  déjà presque tous ces conventions.  Cette approche  est  déclarative et le 
développeur ne perd pas de temps à écrire divers fichiers de configuration indiquant comment son 
projet est structuré.

/projet
/src
/main
/resources
/java
/test
/resources
/java
/target
pom.xml
LICENSE.txt
NOTICE.txt
README.txt

 Architecture 4.1: Hiérarchie d'un projet Maven

Le dossier src contient les différentes sources du projet (et également les sources des tests). Le 
dossier target contient le code compilé ainsi que l'archive du projet. Plus d'informations concernant 
la structure d'un projet Maven peuvent être trouvées dans [4] et au Chapitre 1 de [5] 

 4.3  Gestion des dépendances

La   gestion   des   dépendances   est   complètement   gérée   par   Maven.   Maven   possède   un   dépôt 
central7    où   sont   stockés   plusieurs   giga   octets   d'archives   jar.   Ces   archives   peuvent   être   des 
bibliothèques comme Junit, Jdom, etc..).

<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.4</version>
</dependency>
</dependenci

7 http://repo1.maven.org/maven2/

8
 Listing 4.2: Ajout de la dépendance Junit dans un projet Maven

Toutes les dépendances du projet doivent figurer à l'intérieur du tag <dependencies>. Maven 
va  alors automatiquement rechercher dans les dépôts connus (Nous allons voir  au Chapitre  5 
comment gérer son dépôt privé) afin de télécharger la dépendance et l'ajouter au projet.

Les   tags  groupId,  artifactId  et  version  ont   exactement   la   même   signification   que   les 
informations figurant dans l'en­tête du POM (voir Chapitre 4.1)

 4.4  La notion de plugins

Maven fonctionne à l'aide de plugins. Chaque plugin est généralement associé à un but précis 
(compiler le projet, créer une archive JAR, etc...). La liste complète des plugins officiels peut être 
trouvée dans [6]

D'autres plugins non­officiels peuvent également être installés. Prenons par exemple le cas d'une 
application   Android.   Une   application   Android   est   écrite   en   Java,   mais   nécessite   des   étapes 
différentes de construction en comparaison à une application Java SE ou Java EE.

Le plugin maven­android­plugin8 permet de résoudre ces différents problèmes.

Son activation s'effectue en ajoutant une dépendance de plugin dans le fichier pom.xml

<plugin>
<groupId>com.jayway.maven.plugins.android.generation2</groupId>
<artifactId>maven-android-plugin</artifactId>
<version>2.5.2</version>
<configuration>
<sdk>
<path>/usr/local/andrdoid/sdk</path>
<platform>2.1</platform>
</sdk>
<emulator>
<avd>Nom de l'emulateur</avd>
</emulator>
</configuration>
</plugin>
Listing 4.3 : Ajout d'un plugin pour gérer une application Android 

Le plugin sera téléchargé (S'il n'est pas déjà présent dans le cache local) puis utilisé pour 
construire l'archive Android.

 4.5  Cycle de vie de construction

Comme   dit   précédemment,   Maven   est   composé   d'un   élément   fondamental :   les   plugins.   Un 
deuxième élément entre en compte dans la construction du projet : le cycle de vie.

8 http://code.google.com/p/maven­android­plugin/

9
Maven   construit   tous   les   projets   de   la   même   manière.   Il   exécute   ses   tâches   sous   forme   de 
différentes phases ordonnées en y associant un ou plusieurs plugins correspondant.
Phase Description Plugin
process-ressouces Traitement des ressources  maven­ressouces­plugin
utilisées dans le projet
compile Compilation des fichiers  maven­compiler­plugin
sources
process-test-ressouces Traitement des ressources  maven­ressouces­plugin
utilisées dans les tests
test-compile Compilation des tests maven­compiler­plugin
test Exécution des tests maven­surefire­plugin
package Création de l'archive (jar, war,  maven­jar­plugin
ear, apk9, ...) maven­war­plugin
maven­ear­plugin
maven­android­plugin10
install Installation de l'archive maven­install­plugin
deploy Déploiement de l'archive maven­deploy­plugin
Tableau 4.1 : Différentes phases et plugins de Maven

Cette liste est bien entendue non exhaustive. Cependant les phases décrites dans le  Tableau 4.1 
sont les plus représentatives. Certains plugins comme maven­compiler­plugin, peuvent être utilisés 
lors de plusieurs phases.

Maven permet également d'associer de nouveaux plugins à chacune de ses phases, ce qui permet 
de construire pratiquement n'importe quel projet de n'importe quel langage (Pour autant que le 
plugin existe).

 4.6  Héritage de projets et modules

Dans un logiciel composé de différents modules, les modules seront probablement des projets à 
part entière. De ce fait, Maven permet de découper un projet en plusieurs autres projets.

Il   est   possible   de   configurer   un   projet   « logique »   permettant   d'inclure   les   différents   modules 
utilisés.

9 Archive d'une application Android
10 Le plugin est choisi suivant l'archive spécifiée dans le pom.xml. Par défaut, le plugin maven­jar­plugin est choisi et 
une archive jar est construite.

10
<groupId>ch.exemple.app.test</groupId>
<artifactId>Test</artifactId>
<version>1.0-SNAPSHOT</version>
<name>Application (POM)</name>

<!-- Indique un projet logique -->

<packaging>pom</packaging>

<modules>
<module>Module1</module>
<module>Module2</module>
<module>Module3</module>
</modules>
Listing 4.4: Une application composée de 3 modules

Les modules doivent également indiquer quel est le projet parent.

<parent>
<groupId>ch.exemple.app.test</groupId>
<artifactId>Test</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
Listing 4.5: Indication d'un projet parent

En faisant ce type d'héritage, il est alors possible de mettre en commun certaines informations et 
de découper son projet en plusieurs sous­projets.

Au niveau de la structure, les dossiers des sous projets (modules) doivent se trouver au même 
niveau que le fichier POM du parent.

Illustration 2: Un projet Maven sous 
Netbeans composé de 3 modules 

 4.7  Création d'un archétype

Dans le terminologie Maven, un archétype est un modèle de projet. Il permet lors de la création 
d'un nouveau projet d'ajouter directement certaines informations, comme des fichiers au projet.

Un archétype est également un projet Maven contenant les différentes ressources nécessaires à la 
création d'un projet vide.

11
On peut par exemple imaginer l'utilisation suivante : pour chaque projet créé, on ajoute l'URL de 
notre dépôt privé dans le fichier POM ainsi qu'un fichier LICENSE.txt à la racine du projet.

Illustration 3: Archétypes disponibles (Vue depuis Netbeans)

Plus d'informations concernant la création d'archétypes peut être trouvé dans [7]

12
 5 Gestion d'un dépôt d'artefacts
Dans le Chapitre 3 sur Subversion, nous nous sommes posés la problématique du stockage des 
librairies externes et des artefacts produits par l'entreprise.

L'utilisation d'un gestionnaire de dépôt (Repository Manager) va nous permettre de trouver une 
solution   à   notre   problème.   Nous   pouvons   souligner   le   fait   que   Maven   utilise   cette   approche 
concernant le dépôt central (Maven Repository Manager11).

Au cas où une libraire externe ne figurerait pas dans le dépôt central de Maven (par exemple 
javax.jms ou com.oracle.ojdbc qui demandent l'acceptation d'une licence pour être utilisées). ll est 
possible de configurer son propre dépôt privé sur son serveur et d'ajouter ensuite ces artefacts.

Il  existe   par  exemple   différents   logiciels   permettant   de   gérer   son   propre   dépôt.   Citons   à   titre 
d'exemple Archiva12, Artifactory13 et Nexus14. Ce dernier sera présenté dans ce chapitre.

 5.1  Nexus

Nexus est un gestionnaire d'artefacts Open Source maintenu par le société  Sonatype. Il existe 
également  un version professionnelle avec plus de fonctionnalités.  La documentation complète 
concernant l'installation et l'utilisation de Nexus peut être trouvée dans [8]. 

 5.2  Ajout de son dépôt 

Sous Nexus, il est possible de configurer plusieurs types de dépôts :

• Hosted Repository
• Proxy Repository
• Virtual Repository

Les  Hosted Repository  sont les dépôts locaux. Ils  peuvent  être  de deux  types :  les dépôts de 

releases  et   les   dépôts   de   snapshots.  Comme   expliqué   au   Chapitre  4  Maven,   les   versions 
snapshots  sont   des   versions  en   cours   de   développement  dont  les   fichiers   exécutables   (.jar, 
.war, ...) sont susceptibles de changer très régulièrement.

Figure 5.1: Création d'un nouveau dépôt dans Nexus

11 http://repo1.maven.org/maven2/
12 http://archiva.apache.org/
13 http://www.jfrog.org/products.php
14 http://nexus.sonatype.org/

13
Les Proxy Repository permettent d'accéder à un dépôt distant et de mettre en cache les différents 
artefacts   téléchargés   par   les   développeurs.   Cela   permet   de   minimiser   le   trafic   réseau   vers 
l'extérieur de l'entreprise et d'utiliser le dépôt privé comme dépôt central Maven.

Les Virtual Repository permettent quant à eux d'effectuer une copie d'un ou plusieurs dépôts.

 5.3  Ajout d'un nouvel artefact

Il existe plusieurs possibilités pour ajouter un artefact sur le dépôt. La première s'effectue en se 
connectant à Nexus et en sélectionnant le fichier à ajouter. Avec cette méthode il faut spécifier à la 
main les informations groupId, artifactId, version . Cette première méthode est utilisée par 
exemple pour ajouter des versions release qui ne figurent pas sur le dépôt central.

Concernant   les   versions  SNAPSHOT,     la   deuxième   possibilité   s'effectue   généralement 

directement dans la phase de déploiement d'un projet (Phase deploy)

Figure 4: Exemple d'ajout de l'artefact ojdbc5 de Oracle

Pour spécifier le déploiement d'un artefact sur un dépôt privé le fichier POM doit être complété 
pour indiquer le dépôt à utiliser.

<distributionManagement>
<snapshotRepository>
<id>geosSnapshots</id>
<url>http://nexus.exemple.ch:8080/nexus/content/
repositories/geosSnapshots</url>
</snapshotRepository>
</distributionManagement>
Listing 5.1: Distribution d'une archive sous un dépôt privé 

Au cas où le dépôt serait protégé par un mot de passe, celui­ci doit être spécifié  dans le fichier 
.settings.xml

Le déploiement s'effectue à proprement parler à l'aide de la commande mvn deploy

14
L'artefact peut ensuite être sans autre associé comme dépendance à un autre projet (Chapitre 
4.3 Gestion des dépendances). Il sera téléchargé directement depuis le dépôt privé de l'entreprise.

15
 6 L'intégration continue

 6.1  But de l'intégration continue

L'intégration   continue   est   une   technique   de   génie   logiciel   permettant   de   vérifier   si   un   logiciel 
fonctionne toujours après que le code source soit modifié. Cette technique permet de vérifier qu'il 
n'y a pas de régression entre chaque modification.

L'équipe de développement doit intégrer son travail de manière fréquente. Cette technique peut se 
faire manuellement, ce qui peut bien sûr être efficace pour les petits projets, mais pas pour des 
projets conséquents.

Certains outils permettent actuellement d'effectuer cette intégration de manière automatique et à 
intervalle   régulier.   Ces   logiciels   travaillent   généralement   de   manière   très   étroite   avec   un 
gestionnaire de code source ainsi qu'un système de construction de projet tel que Maven.

Pour vérifier qu'il n'y a pas de régression, ces outils essayent déjà de compiler le projet. S'il y a 
une erreur de compilation, il y a déjà une indication comme quoi il y a un problème avec le code et 
qu'un le développeur à soumis des sources non compilables.  Si le projet se compile, les tests 
unitaires sont exécutés pour vérifier que ces tests sont tous réussis lors de l'intégration.

 6.2  Hudson

Hudson est un outil d'intégration continue écrit en Java. Il est disponible sous forme d'archive .war 
et peut être déployé sur un serveur d'application comme Glassfish15  ou un conteneur de servlet 
comme Tomcat16.

Une   fois  l'environnement   d'intégration  installé  il   est  nécessaire   de  configurer  ses  projets.  Pour 
chaque projet il est possible de configurer les paramètres suivants :

• Serveur SVN (afin de récupérer la dernière version du code)
• Paramètres de build
• A quelle période ou lors de quel événement créer le build.
• Des notifications email lors d'un échec de build
• Le déploiement de l'artefact en cas de succès.

15 http://glassfish.java.net/
16 http://tomcat.apache.org/

16
 Illustration 5: Deux projets (appelés jobs dans Hudson) monitorés

Notons également que l'installation de Hudson sur un serveur nécessite l'installation de Maven (Et 
oui, il faut bien que Hudson puisse compiler le projet !)

Lorsqu'un   événement   indique   qu'il   faut   commencer   à  construire   le   projet,   Hudson   effectue   les 
étapes suivantes :

• Mise à jour d'une copie locale du code depuis le SVN.
• Appel de Maven afin de compiler le projet
• Notifications en cas d'erreur

Figure 6.1: Le build est construit correctement après 14mn de compilation

Hudson permet également de faire du monitoring de tâches externes. Par exemple lancer une 
tâche périodiquement ou vérifier que notre système (NDR : notre application) est toujours en vie. 

Ces   aspects   avancés   n'entre   pas   dans   le   contexte   de   ce   rapport   mais   l'utilisateur   qui   serait 
intéressé par ces concepts trouvera plus d'informations dans [9].

17
 7 Analyse de code
L'analyse de code vérifie non pas la fonctionnalité du code produit mais plutôt sa complexité. Elle 
vérifie également que tout les normes de codage sont appliquées.

Différents   outils   existent.   Dans   ce   rapport   nous   nous   intéresseront   à   Sonar   puisqu'il   s'intègre 
particulièrement bien avec notre architecture.

 7.1  Sonar

La génération  de  métriques pour  un projet  nécessite un plugin  pour  Maven.  Celui­ci peut   être 

ajouté en spécifiant les informations suivantes dans notre fichier POM.

<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>1.0-beta-2</version>
</plugin>
<plugins>
</build>
Listing 7.1: Ajout du plugin Sonar dans un projet

La   configuration   des   paramètres   du   plugin   s'effectue   en   définissant   différentes   variables   à 

l'intérieur du fichier pom.xml ou settings.xml.

<properties>
<sonar.jdbc.url>
jdbc:mysql://localhost:3306/sonar?
useUnicode=true&amp;characterEncoding=utf8
</sonar.jdbc.url>
<sonar.jdbc.driver>com.mysql.jdbc.Driver</sonar.jdbc.driver>
<sonar.jdbc.username>sonar</sonar.jdbc.username>
<sonar.jdbc.password>sonar</sonar.jdbc.password>
<sonar.host.url>http://localhost:8080/sonar/</sonar.host.url>
</properties>
Listing 7.2: Configuration du plugin Sonar

L'activation du plugin pour Sonar s'effectue avec la commande suivante :

mvn sonar:sonar

Sonar et son guide complet d'installation peut être trouvé dans [10]

18
 8 Conclusion
Il   est   évident   que   la   solution   proposée   est   une   solution   parmi   d'autres.   Celle­ci   à   néanmoins 
l'avantage d'être parfaitement générique et modulable. Le fait qu'elle se base entièrement sur des 
logiciels open sources la rends également libre de toute modification.

La   solution   à   l'avantage   d'être   applicable   à   n'importe   quel   projet.   Qu'il   soit   grand   ou   petit. 
Cependant, il faut garder à l'esprit que la mise en place d'une telle architecture prends du temps et 
qu'elles n'est peut être pas efficace pour des petites équipes. Théoriquement, cette solution est 
applicable à un projet fait dans n'importe quel langage (ou plusieurs) grâce au plugins de Maven.

L'usage de logiciels open source dans cette solution ont été des choix personnels (D'ailleurs la 
rédaction complète de ce rapport a été effectué sur Open Office17 sous un système Linux Fedora, 
c'est pour dire...). Ces choix se sont avérés pleinement satisfaisants.

A l'heure actuelle cette « software factory » (Terme très à la mode...) est une des plus utilisées 
dans le monde professionnel. Cette affirmation s'appuie sur différentes expériences passées.

Tout ces logiciels sont en constante évolution. Prenons par exemple le cas de la version 3 de 
Maven (sortie de novembre 2010) supportant le multithreading pour permette la compilation plus 
rapide sur des machines multicoeurs. 

17 http://fr.openoffice.org/

19
 9 Bibliographie
[1] Ben Collins­Sussman,  Brian W. Fitzpatrick et C. Michael Pilato, Subversion redbook, 
http://svnbook.red­bean.com/, visualisé en novembre  2010
[2] MASON Mike, Subversion, Pratique du développement collaboratif avec SVN, 2006, Editions 
Eyrolles 
[3] Apache foundation, SVN Best Practices, http://goo.gl/wbt0O, visualisé en novembre  2010
[4] Projet Maven, Maven Standard Directory Layout, http://goo.gl/lm18Y, visualisé en novembre 
2010
[5] DE LOOF Nicolas et HERITIER Arnaud, Apache Maven, 2009, Editions Pearson 
[6] Projet Maven, Plugins Maven, http://maven.apache.org/plugins/index.html, visualisé en 
novembre  2010
[7] Projet Maven, Guide to create Archetype, http://goo.gl/zLIli, visualisé en novembre  2010
[8] Projet Nexus, Nexus Book, http://www.sonatype.com/books/nexus­book/reference, visualisé en 
octobre  2010
[9] Projet Hudson, Site wiki officiel du projet Hudson, http://wiki.hudson­
ci.org/display/HUDSON/Home, visualisé en octobre  2010
[10] Projet Sonar, Sonar download and install guide, http://www.sonarsource.org/downloads/, 
visualisé en novembre  2010

20