Octo Maven.pdf

© OCTO Technology 2008
Maven
Paris VI – UPMC
Master Science et Technologies du Logiciel
Technologies Applicatives
Mardi 11 Mars 2008

Arnaud Héritier
 OCTO Technology
 Expert sénior
 aheritier AT octo DOT com
 http://www.octo.com
 Maven
 Committer depuis 2004 et membre du Project Management
Committee depuis 2005
 Aheritier AT apache DOT org
 http://maven.apache.org
 DESS GLA promo 1999.
© OCTO Technology 2008 2

OCTO Technology - Fiche
d’identité
 Une communauté de 90 architectes
et experts
 S’enrichissant mutuellement à la
fois sur le métier, sur la technique
et sur le logiciel
 Désireux de comprendre le métier
de leurs clients
 Prenant plaisir à travailler
ensemble
 Une croissance organique maîtrisée
et continue depuis sa création (+
30% chaque année)
 Fondé en 1998, OCTO est un Cabinet de Conseil en Architecture des
Systèmes d'Information.

OCTO Technology - Prestations :
une offre innovante
 Assister dans le pilotage des
Systèmes d’Information
 Qualité, et pas uniquement coûts et
délais
 Construire et transformer le
patrimoine applicatif pour:
 Tirer le meilleur parti des
technologies de l’information
 Accélérer leur mise en œuvre grâce
à une forte expertise technique et
méthodologique
 Industrialiser ces pratiquesau sein
des DSI : capitaliser, et rationaliser
dans la durée
Le savoir faire d’OCTO couvre tout le cycle de vie d’un
Système d’Information :

Agenda
 Théorie
 Présentation générale
de Maven
 Maven, les concepts
 Démarrer un projet
avec Maven
 Contrôle qualité
 Indicateurs de reporting
 Le projet sous tous ses
angles
 Pratique
 Questions / Réponses
 et / ou
 Exemple live

Présentation générale de
Maven
 Un peu d’archéologie
 Maven en 3 questions
 Maven un remède à vos douleurs ?

Un peu d’archéologie
JCL
Make
Ant
Maven

Maven en 3 questions
 C’est quoi ?
 Un outil de type batch (Windows) / shell (Unix)
 Une philosophie
• Application des bonnes pratiques et patterns de développement Java
 Ça sert à quoi ?
 Construire une application
• Compiler, tester
• Contrôler et produire des packages livrables
• Publier les documentations et les rapports sur la qualité
 Ça apporte quoi ?
 Simplification du processus de construction d’une application
 Fournit des bonnes pratiques de développement
 Tend à uniformiser le processus de construction
 Vérifie la qualité du code
 Beaucoup moins de maintenance qu’un script (Ant, shell …)
http://maven.apache.org/guides/getting-started/

Maven, un remède à vos
douleurs ?
Problématiques RéponsesMaven
Gestion des librairies du projet
(versions, partage, ..)
Dépendances déclaratives
Dépendances transitives
Référentiels de librairies
Multiplication des scripts de
build(écriture, maintenance)
POM
Plugins
Mauvaise qualité des livrables Contrôles
Reporting
Standardisation des projets
(JEE)
Standardisation du build
Travail collaboratif (multi-sites) Intégration aux différents outils
(gestionnaire de versions,
d’issues, …)
Site documentaire

Maven, les concepts
 Descripteurs de projets
 Cycle de vie et plugins
 Référentiels de librairies

Descripteurs de projets (1/5)
 Descripteurs de projets : Project Object Model (« POM »)
 Base de travail de Maven
• Un projet Maven est un module d’une application
• Équivalent à un projet Eclipse
 Fichier xml (pom.xml) décrivant le projet Maven
• Version du projet
• Description du projet
• Liste des développeurs
• …
 Ce fichier est utilisé par Maven pour construire l’application
• Dépendances de l’application (librairies jar)
• Tâches (ou « goals ») à exécuter
 Fournit des valeurs par défaut (bonnes pratiques)
• Ex : répertoire des sources « src/main/java »
 Un seul POM est nécessaire par projet
• Les commandes Maven sont à exécuter à la racine du projet où se situe le
fichier pom.xml
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html

 Le POM minimal
 La racine du projet (<project>)
 La version du modèle de POM (<modelVersion>)
• 4.0.0 pour Maven 2.0.x
 L’identifiant du groupe auquel appartient le projet (<groupId>)
• Généralement commun à tous les sous projets d’un projet
 L’identifiant de l’artefact à construire (<artefactId>)
• Généralement le nom du projet sans espaces (-) en minuscules
 La version de l’artefact à construire (<version>)
• Toujours en SNAPSHOT sauf lors de la release
 Le type d’artefact à construire (<packaging>)
• pom, jar, war, ear
 Exemple :
http://maven.apache.org/pom.html
http://maven.apache.org/ref/2.0.4/maven-model/maven.html

 Caractéristiques du projet
 Description du projet
• Informations diverses sur le projet
 Dépendances
• Liste des librairies utilisées
• Précision du scope de la librairie
• Exclusion des dépendances transitives

 Phase de construction du projet
 Description de la construction
• Agencement des répertoires
• Tâches (goals)
• Gestion des ressources du projet
• En grande partie configurée par défaut
 Gestion des plugins (optionnel)
• Utilisation de plugins existants
• « Tâches » personnalisées
– Possibilité de créer des plugins
 Gestion des rapports (optionnel)
• Choix des rapports à générer
• Utilisation de plugins dédiés

 Configuration de l’environnement
 Configuration des référentiels (repo)
• Sélection du ou des repos distants
 Lien au gestionnaire de sources
• Possibilité de le piloter
 Lien au gestionnaire de bugs
• Essentiellement pour la doc
 Lien à l’intégration continue
 Mailing-list

Cycle de vie et plugins (1/3)
 Cycle de vie et « plugins »
 Maven est basé sur la notion de cycle de vie de construction (build)
 Il s’agit du processus mis en œuvre pour construire l’application
• Processus défini par Maven (bonnes pratiques)
 Ce processus est basé sur des plugins
• Les plugins sont des fonctionnalités de l’outil
– Le noyau de l’outil ne fait que de la gestion des pom, des repos et des settings
• Chaque plugin apporte de nouvelles commandes exécutables par Maven
 Les plugins sont des ensembles (fonctionnels) de traitements
• Ex. : le plugin « compiler » permet de compiler des sources et des tests
• Chaque traitement peut être associé à une phase du cycle de build
 À partir d’une commande, Maven déroule toutes les étapes nécessaires pour
atteindre la phase du cycle de vie en question
• Ex. : pour la commande « package », Maven compile, test, et package
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

Cycle de vie et plugins(2/3)
 Cycle de vie commun
 validate
• Vérifie que le projet est correct et toutes les informations nécessaires présentes
 compile
• Compile les sources du projet
 test
• Teste les sources compilées à l’aide d’un framework de tests unitaires (ex : JUnit)
 package
• Prend les sources compilées et génère un package distribuable (ex : Jar)
 verify
• Vérifie que le package généré est correct
 install
• Installe le package dans le repo local pour pouvoir être utilisé comme dépendances par d’autre projets
locaux
 deploy
• Déploie le package dans un repo distant pour pouvoir être utilisé comme dépendances par d’autre projets
 Commandes communément utilisées
 Basé sur le type de projet précisé dans le POM (<packaging>jar, war, ear, pom</packaging>)
validate compile test package verify install deploy

Cycle de vie et plugins(3/3)
 Plugins fréquemment utilisés
 site : génère un site documentaire pour le projet
 jar / war /ear : génère un package de l’application (~ package)
 javadoc : génère la javadoc du projet
 archetype : génère un projet (arborescence + pom.xml)
 eclipse : génère les fichiers d’Eclipse (.project, .classpath)
 antrun : exécute des tâches ant pendant le build
 checkstyle, pmd… : analysent le code et génèrent un rapport

Référentiels de librairies (1/3)
 Référentiel de librairies (« Repository »)
 Espace de stockage et partage des artefacts
• Descripteurs de projets
– Gestion des dépendances transitives
• Les livrables binaires des projets et librairies (API, frameworks…)
– jar, war, ear,…
– Remplace les répertoires « lib » des projets
– Conserve les différentes versions de chaque librairie
• Documentation
– Javadoc
 Utilisé par Maven pour compiler et tester l’application
• Librairies utilisées par l’application
 Deux types de référentiels
• Local : instance mono-utilisateur (Ex. : sur un poste de travail)
• Distant : instance servant uniquement d’espace de stockage et de diffusion des
artefacts entre plusieurs utilisateurs
http://maven.apache.org/guides/introduction/introduction-to-repositories.html

Référentiel de
librairies distant
Référentiels de
librairies distant
(Maven, Ibiblio,
codehaus)
Usine de
développement
Poste de travail
Maven
Référentiel local
(librairies + sites)
Référentiel de
librairies local
Maven
Entreprise INTERNET
Proxy
Poste de travail
Référentiel de
librairies local
Maven

1. L’utilisateur tape la commande « mvn compile »
2. Maven lit les dépendances du POM
3. Maven recherche chaque dépendance
A. Dans le référentiel local
B. S’il ne trouve pas en local,
a) Maven recherche dans le référentiel distant
b) Maven télécharge la dépendance et la positionne dans le référentiel local

Démarrer un projet avec
Maven
 Projet simple
 Projet multi-modules
 Héritage de projets

Démarrer un projet « from
scratch » (1/2)
1. Créer le projet à l’aide de Maven
 Utiliser le plugin maven-archetype* pour générer l’arborescence et le
descripteur de projet pom.xml
• Ex java :
» mvnarchetype:create
» -DgroupId=com.societe.projet
» -DartifactId=projectSimple
• Ex application web :
» mvnarchetype:create
» -DgroupId=com.societe.projet
» -DartifactId=projectWeb
» -DarchetypeArtifactId=maven-archetype-webapp
* http://maven.apache.org/plugins/maven-archetype-plugin/

Démarrer un projet « from
scratch » (2/2)
2. Importer le projet dans Eclipse
 Utiliser le plugin maven-eclipse* pour
générer les fichiers nécessaires à l’import
sous eclipse (.classpath, .project)
• Ex : mvn eclipse:clean eclipse:eclipse
 Importer le projet sous eclipse
• File / Import / Existing project
into Workspace
* http://maven.apache.org/plugins/maven-eclipse-plugin/

 Un projet multi-module est un projet composé de plusieurs modules ou projets
 Permet depuis le projet « englobant » de compiler, tester packager l’application
(l’ensemble des modules) en une seule commande Maven
 Ex : project est un projet multi-module contenant les projets projectSimple et
projectWeb
 Écriture du POM
 Intérêts du multi-module
 Séparation des builds de même qu’on sépare les fonctionnalités en programmation
orientée objet (POO)
 Modularité et réutilisabilité de l’application (certaines parties au moins)
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.societe.projet</groupId>
<artifactId>project</artifactId>
<version>1.0-SNAPSHOT</version>
<name>Main Project</name>
<modules>
<module>projectSimple</module>
<module>projectWeb</module>
</modules>
</project>
Agrégation de projets (multi-
module)

<project>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
<project>
<parent>
<version>1.0-SNPASHOT</version>
</parent>
<artifactId>projectSimple</artifactId>
<packaging>jar</packaging>
</project>
 Un projet peut hériter des informations d’un projet parent
 Le POM du projet fils hérite du POM du projet père
• Les dépendances, les plugins, les rapports
 Ex : projectSimple et projectWeb nécessitent JUnit 3.8.1
• On fait hériter projectSimple et projectWeb de project
• On précise dans le POM de project la dépendance
 Écriture des POM
 Intérêts de l’héritage
 Hériter des caractéristiques communes de sous projets de même qu’on hérite d’une classe en POO
 Centraliser l’information dans un seul descripteur (ex: éviter la montée de version d’une librairie dans 5 projets)
 Possibilité de coupler héritage et agrégation
 Le projet parent contient les projets fils et gère les caractéristiques communes des projets fils
Héritage de projets

Contrôle qualité
 Qualité du code source
 Qualité de l’application
 Qualité des développements

Contrôle qualité
Qualité du code source Qualité des développements
Code Tests Unitaires
Règles
d’écriture
Architecture
Complexité Anomalies /
Bugs
Suivi de charge Fonctionnalités
livrées
Évolution de
l’application
Code modifié
Charge de
développement
Tableau de
bord
Design
Qualité de
l’application
Tests Fonc. /
non Fonc.
Résultats
Couverture
Pilotage
Résultats
Couverture
Publication

Qualité du code source
 Qualité du design et du code
 Vérification de l’architecture de l’application
• Réutilisabilité, extensibilité, maintenabilité
• Dépendances entre classes / packages
 Vérification des standards de programmation
• Convention d’écriture Java
1
• Bonnes pratiques (présence de mauvaises pratiques)
• Présence de javadoc
 Vérification de la complexité du code
• Code non optimal
• Code dupliqué
1 : http://java.sun.com/docs/codeconv/

Indicateurs de qualité

Qualité du code source et de
l’application
 Qualité des tests (unitaires / fonctionnels / performance)
 Vérification du passage des tests
• Passage au vert (OK) de tous les tests
 Vérifier que les tests passent ne suffit pas
• Présence de tests inutiles
• Couverture faible ou sur des parties sans intérêt du code
 Vérifier la couverture des tests
• Pourcentage du code testé
 Mettre en relation ces résultats avec le nombre de bugs toujours
présents
• Un code 100 % testé mais avec de nombreux bugs est mal testé

Qualité des développements
 Suivre l’évolution des développements
 Commit quotidien ou non
 A mettre en relation avec les délais d’intégration, la qualité du code et des
tests
 Suivre la cadence des livraisons
 Nombre de fonctionnalités livrées dans un lot
 Nombre de bugs corrigés / bugs restants / nouveaux bugs
 Rapport entre charges des développements et fonctionnalités livrées /
anomalies corrigées
 Utilisation du gestionnaire d’issues et du gestionnaire de versions, CVS
pour obtenir les informations
 Calcul de la vélocité des développements
 Pour mieux estimer les charges et délais des nouvelles tâches

Indicateurs
 PMD
 FindBugs
 Checkstyle
 Cobertura

Critères analysés
 Design
 Analyse des problèmes de conception / d’architecture de l’application
• Méthodes / classes trop longues, copiers-collers, …
 Lisibilité du code
 Analyse du code et des conventions d’écriture pour éviter des problèmes
de maintenabilité
• Accolades autour des blocs if/while/for, code mort (champs ou méthodes inutilisés), …
 Robustesse
 Analyse des problèmes pouvant engendrer un crash de l’application
• Gestion des Exceptions, gestion des Threads
 Analyse des problèmes pouvant engendrer un comportement anormal de
l’application
• Comparaisons d’objets ou de chaînes, …

Critères analysés
 Performances
 Analyse statique des problèmes pouvant engendrer des mauvaises
performances de l’application
• Threads, mauvaise usage des chaînes, …
 Sécurité
 Analyse les problèmes de sécurité du code pouvant engendrer un
comportement anormal ou des crashs
• Problèmes d’introspection, travail en équipe
 Test
 Analyse les tests unitaires pour éviter les tests vides ou sans assertions
 Analyse la présence de tests sur la plus grande partie du code
(vérification de la couverture)
 Documentation
 Vérifie la présence de documentation complète sur les méthodes et
classes

Indicateurs du site
 Les indicateurs remontés par le site concernent
essentiellement la qualité du code source
Qualité du code source
Code Tests Unitaires
Règles
d’écriture
Architecture
Complexité
Design
Résultats
Couverture
Surfire
PMD /
Checkstyle
PMD /
Findbugs
Cobertura
PMD /
Findbugs

Indicateurs du site
 Tous les indicateurs de qualité du code sont générés par
des plugins Maven de reporting
 Ces plugins sont généralement utilisés par le plugin « site »
 mvn site appelle tous les plugins reporting
 Chaque plugin génère un ou plusieurs fichiers xml de résultat
 Le plugin site agrège tous les rapports sous forme de site web

PMD
 Détection d’exceptions potentielles
 NullPointerException
 Mauvaise gestion des exceptions
 Blocs catch vides
 Remontée de nouvelles exceptions
 Détection de ressources non fermées
 Connections à la base
 Flux de fichiers (Streams)
 Détection de code mort
 Méthodes, champs, blocs non utilisés
 Détection de code non optimal
 Expressions trop complexes
 Mauvaise utilisation des Strings
 Possibilité de personnaliser les règles à vérifier
 rulesets.xml
 Possibilité de faire échouer le build
 pmd:check
http://pmd.sourceforge.net/
http://maven.apache.org/plugins/maven-pmd-plugin/

Findbugs
 Détecte des mauvaises pratiques pouvant engendrer un
plantage ou un comportement anormal
 Oubli d’exception
 Mauvaise utilisation de equals et hashCode
 Possibilité de filtrer les règles à vérifier
 includeFilter (xml)
 visitors (règles)
 threshold (criticité)
http://findbugs.sourceforge.net/
http://mojo.codehaus.org/findbugs-maven-plugin

Checkstyle
 Vérifie le style de programmation
 Détecte la mauvaise lisibilité du code
• Manque d’accolades
• Méthodes trop longues ou avec trop de paramètres
 Détecte les copiés collés
 Vérifie la javadoc
• Présence de commentaires sur les méthodes et classes
 Détecte des problèmes possibles de robustesse
 Détecte la mauvaise utilisation des == et != au lieu de equals
 Détecte la mauvaise utilisation de this
 Possibilité de filtrer les règles à vérifier
 Fichier xml
http://checkstyle.sourceforge.net/
http://maven.apache.org/plugins/maven-checkstyle-plugin/

Surfire-report et Cobertura
 Surfire-report
 Résultat de l’exécution des tests
 Cobertura
 Couverture des tests
 Possibilité de faire échouer le build
si le pourcentage de code couvert
n’est pas suffisant
http://cobertura.sourceforge.net/
http://mojo.codehaus.org/cobertura-maven-plugin/
http://maven.apache.org/plugins/maven-surefire-report-plugin/

JXR et Javadoc
 JXR
 Génération du code en HTML
 Facilite le parcours du code
 Lié aux autres plugins
• Affichage rapide des erreurs
 Possibilité de lier à la doc
 Javadoc
 Génération de la javadoc
 Gère le multi-module

Le projet sous tous ses
angles
 Du point de vue du développeur
 Du point de vue du responsable qualité
 Du point de vue du gestionnaire de release

Du point de vue du développeur
 Utilisez maven pour valider vos développement (passage
de tous les tests automatisés et génération du livrable)
 Le support des IDEs est variable.
 Bon dans NetBeans
 Moyen dans Eclipse (projets Q4E, m2eclipse)
 Les plugins générant la config depuis maven
(eclipse:eclipse, …) offrent la plus grande palette de
services

Du point de vue du responsable
qualité
 Attention a bien sélectionner les indicateurs remontés.
Trop d’informations tue l’information.
 Utiliser un serveur d’intégration continue pour valider
l’ensemble des développements (tests, qualité, …) et
générer le reporting.
 Adosser un système de suivi des indicateurs (Sonar par
exemple) pour contrôler leurs évolutions au fur et à
mesure.

Du point de vue du
gestonnaire de release
 Laissez maven faire se travail pour vous.
 Les pré-requis
 Les binaires SVN
 Les élements du POM
 scm
 distributionManagement (fourni par le pom parent)
 Les settings du users
 Le compte pour faire l’upload sur le repo central de l’entreprise
 Les commandes
 release:prepare, release:perform, release:rollback,
release:cleanup

Conclusion
 Maven est-il l’outil miracle ?
 Non, il doit s’inscrire dans une démarche d’industrialisation des
développements
 L’outil n’est pas toujours facile à aborder mais il est lui-même
industrialisable
 C’est un projet OSS avec ses avantages et ses inconvénients
 Pour en savoir plus
 Deux livres sont disponibles gratuitement sur sonatype.com et
devzuz.com
 De nombreux bloggeurs donnent leur avis positif ou négatif….. À
vous de vous faire le votre désormais.

Et maintenant ?
Questions & Réponses Exemple live
ET
OU

Octo Maven.pdf

Recommandé

Recommandé

Contenu connexe

Similaire à Octo Maven.pdf

Similaire à Octo Maven.pdf (20)

Plus de badrfathallah2

Plus de badrfathallah2 (19)

Dernier

Dernier (8)

Octo Maven.pdf