20080311 - Paris Vi Master STL TA - Initiation Maven
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

20080311 - Paris Vi Master STL TA - Initiation Maven

on

  • 2,642 views

Présentation d'une demi journée de Maven en Master à Paris VI

Présentation d'une demi journée de Maven en Master à Paris VI

Statistics

Views

Total Views
2,642
Views on SlideShare
2,640
Embed Views
2

Actions

Likes
1
Downloads
64
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

20080311 - Paris Vi Master STL TA - Initiation Maven Presentation Transcript

  • 1. © OCTO Technology 2008
    Maven
    Paris VI – UPMC
    Master Science et Technologies du Logiciel
    Technologies Applicatives
    Mardi 11 Mars 2008
  • 2. 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
  • 3. © OCTO Technology 2007
    © OCTO Technology 2007
    OCTO Technology - Fiche d’identité
    • Fondé en 1998, OCTO est un Cabinet de Conseil en Architecture des Systèmes d'Information.
    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)
  • 4. © OCTO Technology 2007
    OCTO Technology - Prestations : une offre innovante
    Le savoir faire d’OCTO couvre tout le cycle de vie d’un Système d’Information :
    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
    © OCTO Technology 2007
  • 5. 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
    © OCTO Technology 2008
    5
  • 6. Présentation générale de Maven
    Un peu d’archéologie
    Maven en 3 questions
    Maven un remède à vos douleurs ?
    © OCTO Technology 2008
    6
  • 7. Un peu d’archéologie
    © OCTO Technology 2008
    7
  • 8. © OCTO Technology 2008
    8
    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/
  • 9. Maven, un remède à vos douleurs ?
    © OCTO Technology 2008
    9
  • 10. Maven, les concepts
    Descripteurs de projets
    Cycle de vie et plugins
    Référentiels de librairies
    © OCTO Technology 2008
    10
  • 11. © OCTO Technology 2008
    11
    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
  • 12. © OCTO Technology 2008
    12
    Descripteurs de projets (2/5)
    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
  • 13. © OCTO Technology 2008
    13
    Descripteurs de projets (3/5)
    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
  • 14. © OCTO Technology 2008
    14
    Descripteurs de projets (4/5)
    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
  • 15. © OCTO Technology 2008
    15
    Descripteurs de projets (5/5)
    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
  • 16. © OCTO Technology 2008
    16
    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
  • 17. © OCTO Technology 2008
    17
    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
    • 18. Basé sur le type de projet précisé dans le POM (jar, war, ear, pom)
    validate compile test package verify install deploy
  • 19. © OCTO Technology 2008
    18
    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
  • 20. © OCTO Technology 2008
    19
    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
  • 21. © OCTO Technology 2008
    20
    Référentiels de librairies (2/3)
    Poste de travail
    Poste de travail
    Maven
    Maven
    Maven
    Référentiel local
    (librairies + sites)
    Référentiel de
    librairies local
    Référentiel de
    librairies local
    Référentiel de
    librairies distant
    Référentiels de
    librairies distant
    (Maven, Ibiblio,
    codehaus)
    Proxy
    Entreprise
    INTERNET
    Usine de
    développement
  • 22. © OCTO Technology 2008
    21
    Référentiels de librairies (3/3)
    L’utilisateur tape la commande « mvn compile »
    Maven lit les dépendances du POM
    Maven recherche chaque dépendance
    Dans le référentiel local
    S’il ne trouve pas en local,
    Maven recherche dans le référentiel distant
    Maven télécharge la dépendance et la positionne dans le référentiel local
  • 23. Démarrer un projet avec Maven
    Projet simple
    Projet multi-modules
    Héritage de projets
    © OCTO Technology 2008
    22
  • 24. © OCTO Technology 2008
    23
    Démarrer un projet « from scratch » (1/2)
    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/
  • 25. © OCTO Technology 2008
    24
    Démarrer un projet « from scratch » (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/
  • 26. © OCTO Technology 2008
    25
    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)
  • 27. © OCTO Technology 2008
    26
    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
    <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>
    Héritage de projets
  • 28. Contrôle qualité
    Qualité du code source
    Qualité de l’application
    Qualité des développements
    © OCTO Technology 2008
    27
  • 29. © OCTO Technology 2008
    28
    Contrôle qualité
    Qualité de l’application
    Qualité des développements
    Qualité du code source
    Évolution de l’application
    Charge de développement
    Code
    Tests Unitaires
    Design
    Tests Fonc. / non Fonc.
    Architecture
    Règles d’écriture
    Résultats
    Résultats
    Suivi de charge
    Fonctionnalités livrées
    Complexité
    Couverture
    Couverture
    Anomalies / Bugs
    Code modifié
    Pilotage
    Tableau de bord
    Publication
  • 30. © OCTO Technology 2008
    29
    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/
  • 31. © OCTO Technology 2008
    30
    Indicateurs de qualité
  • 32. © OCTO Technology 2008
    31
    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é
  • 33. © OCTO Technology 2008
    32
    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
  • 34. Indicateurs
    PMD
    FindBugs
    Checkstyle
    Cobertura
    © OCTO Technology 2008
    33
  • 35. © OCTO Technology 2008
    34
    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, …
  • 36. © OCTO Technology 2008
    35
    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
  • 37. © OCTO Technology 2008
    36
    Indicateurs du site
    Les indicateurs remontés par le site concernent essentiellement la qualité du code source
    Qualité du code source
    Code
    Tests Unitaires
    Design
    Surfire
    PMD / Checkstyle
    PMD / Findbugs
    Architecture
    Règles d’écriture
    Résultats
    Cobertura
    PMD / Findbugs
    Complexité
    Couverture
  • 38. © OCTO Technology 2008
    37
    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
  • 39. © OCTO Technology 2008
    38
    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/
  • 40. © OCTO Technology 2008
    39
    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
  • 41. © OCTO Technology 2008
    40
    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/
  • 42. © OCTO Technology 2008
    41
    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/
  • 43. © OCTO Technology 2008
    42
    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
  • 44. 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
    © OCTO Technology 2008
    43
  • 45. 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
    © OCTO Technology 2008
    44
  • 46. 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.
    © OCTO Technology 2008
    45
  • 47. © OCTO Technology 2008
    46
    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
  • 48. 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.
    © OCTO Technology 2008
    47
  • 49. Et maintenant ?
    © OCTO Technology 2008
    48
    ET
    OU
    Questions & Réponses
    Exemple live