20080311 - Paris Vi Master STL TA - Initiation Maven

© OCTO Technology 2008

MavenParis 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

http://www.octo.com/

http://maven.apache.org/

© OCTO Technology 2007© OCTO Technology 2007

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 2007© OCTO Technology 2007

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 pratiques au 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



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/

http://maven.apache.org/guides/getting-started/


Maven, un remède à vos douleurs ?

Problématiques Réponses Maven

Gestion des librairies du projet (versions, partage, ..)

Dépendances déclarativesDépendances transitivesRéférentiels de librairies

Multiplication des scripts de build (écriture, maintenance)

POMPlugins

Mauvaise qualité des livrables ContrôlesReporting

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

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.htmlhttp://maven.apache.org/ref/2.0.4/maven-model/maven.html

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

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html



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



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

http://maven.apache.org/guides/introduction/introduction-to-repositories.html



Référentiel delibrairies 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 delibrairies local

Maven

Entreprise INTERNET

Proxy

Poste de travail

Référentiel delibrairies local

Maven



1. L’utilisateur tape la commande « mvn compile »

2. Maven lit les dépendances du POM

3. Maven recherche chaque dépendanceA. 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 : » mvn archetype:create » -DgroupId=com.societe.projet » -DartifactId=projectSimple

• Ex application web : » mvn archetype:create » -DgroupId=com.societe.projet » -DartifactId=projectWeb» -DarchetypeArtifactId=maven-archetype-webapp

* http://maven.apache.org/plugins/maven-archetype-plugin/

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/

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> <modelVersion>4.0.0</modelVersion> <groupId>com.societe.projet</groupId> <artifactId>project</artifactId> <version>1.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies></project>

<project> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.societe.projet</groupId> <artifactId>project</artifactId> <version>1.0-SNPASHOT</version> </parent> <artifactId>projectSimple</artifactId> <version>1.0-SNAPSHOT</version> <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 Java1

• 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/

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

SurfirePMD / 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/

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

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/

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/

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 liveETOU

20080311 - Paris Vi Master STL TA - Initiation Maven

Documents

librairies octotechnology

repos et

dure octotechnology

documentations et

et membre

et pluginsrfrentiels

technique et sur

mavenun projet maven