Le document traite de l'utilisation d'Apache Maven dans le développement logiciel en entreprise, en abordant ses avantages, la mise en place et l'utilisation quotidienne. Il souligne l'importance de standardisation, de gestion des dépendances, et propose des bonnes pratiques pour structurer un projet. Malgré ses bénéfices, le document avertit que Maven n'est pas une solution universelle et doit être utilisé judicieusement selon les besoins spécifiques des projets.

1. Apache Maven 2 en entreprise… Comment tuer son projet avec Maven ? Comment le réussir ? 15 Juin 2009

2. Arnaud Héritier Committer depuis 2004 Membre du PMC (Project Management Committee) depuis 2005 aheritier AT apache DOT org http://maven.apache.org

3. Arnaud Héritier Aujourd’hui - OCTO Technology Cabinet d’architectes en SI http://www.octo.com Architecte sénior Dans quelques jours - eXo platform Editeur de logiciels http://www.exoplatform.com Software Factory Manager Qualité Outillage Productivité des développements

4. Programme Faire le choix Maven Mettre en place Maven Utiliser Maven au jour le jour Apprendre Maven L’avenir de Maven

5. Programme Faire le choix Maven Pourquoi Maven ? Les intérêts pour un projet Les intérêts pour une entreprise LA solution ? Mettre en place Maven Utiliser Maven au jour le jour Apprendre Maven L’avenir de Maven

6. Pourquoi Maven ?

7. Construction d’un war en 2002 Utilisation d’Eclipse limitée Pas de WTP (uniquement dans la version payante d’IBM), Eclipse ne permettait pas d’exporter des Wars

8. Construction d’un war en 2002 Beaucoup de tâches manuelles Modifier les fichiers de paramétrage Exporter les différents jar Copier les dépendances (et nos jars), dans un répertoire lib Faire un zip que l’on renomme en war Tagguer l’ensemble des sources dans le répertoire de sources (CVS) Envoyer le fichier par FTP sur le serveur d’intégration Se connecter à la console d’administration du serveur et déployer l’application

9. Construction d’un war en 2002 Un seul problème, Y’a toujours des problèmes Erreur dans la configuration Oubli d’une dépendance oubli d’un fichier Correction de dernière minute qui introduit une régression… Autres Combien de temps ça prend ? Quand tout va bien : 15 minutes Quand il y a des problèmes : ½ journée

10. Une première réponse : ANT Ecriture d’un script Permet d’automatiser le process Durée du processus réduite de moitié Le processus ne monopolise personne On le lance et on passe à autre chose

11. Les limites de ANT Ecrire le script, c’est long Modifier un script, c’est très long Au final, le gains de temps n’est pas évident Mais c’est quand même plus amusant Il est possible de réutiliser le script !

12. La réutilisation de scripts ANT Les scripts ne sont pas directement réutilisables Structure de projets différents Besoins différents Encore du temps perdu Modification du script Réécriture pour le rendre plus générique Un nouveau métier s’est créé dans chaque projet : scripteur ANT

13. Quelques exemples J u nit : http://junit.cvs.sourceforge.net/viewvc/junit/junit/build.xml?view=markup Findbugs : http://findbugs.googlecode.com/svn/trunk/findbugs/build.xml J b oss SEAM : http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_0

14. Les intérêts de Maven pour un projet

15. Maven, le choix Projet Le projet peut-être librement découpé en modules Maven ne cristallise pas l’architecture de l’application Gestion des dépendances Déclaratif : Gestion automatique du téléchargement et de l’utilisation dans le projet. Transitivité : On ne déclare que ce que l’on utilise

16. Maven, le choix Projet Centralise et automatise les différents aspects du développement de logiciels Une seule chose qu’il ne peut faire à votre place  : Développer Construction Tests Packaging Déploiement Documentation Contrôles et rapports sur la qualité des développements

17. Les intérêts de Maven pour une entreprise

18. Maven, le choix Entreprise Standard du marché Disponibilité des ressources Standardisation des développements Organisation des sources Descripteur de projet

19. Maven, le choix Entreprise Rationnaliser les coûts On ne réinvente pas la roue à chaque nouveau projet Factorisation entre projets Promotion de la qualité et intégration de l’outillage associé

20. LA solution ?

21. Maven, LA solution ? NON !!! Maven ne répond pas à tous les besoins Choisissez Maven seulement si vous adhérez à son objectif : STANDARDISER En avez vous les moyens ? Ex: standardiser un existant coûte vite cher ! Ant et les autres solutions de scripting peuvent être justifiées.

22. Programme Faire le choix Maven Mettre en place Maven KISS Sécurisation de l’environnement Industrialisation des développements Utiliser Maven au jour le jour Apprendre Maven L’avenir de Maven

23. KISS

24. K.I.S.S. Keep It Simple, Stupid Partez de rien Ne faites pas de sur-architecture ça n’est pas parce que Maven vous propose d’utiliser des modules qu’il faut le faire. Ne testez pas toutes les fonctionnalités de Maven dans votre projet.

25. Sécurisation de l’environnement

26. Sécurisez ! Mettez en place un gestionnaire de proxy des repositories externes Pour se prémunir des défaillances du réseau de l’entreprise des défaillances des repositories externes. Pour faire plaisir à votre infra en diminuant la charge réseau. aux développeurs en diminuant les temps de téléchargement.

27. Sécurisez ! Différents produits gratuits ou payants Sonatype Nexus (remplaçant de Proximity) Jfrog Artifactory Apache Archiva Un groupe unique qui fait proxy vers tous les repos externes Déclaration d’un mirroir * dans les settings de tous les développeurs

28. Settings avec un miroir global <settings> <mirrors> <mirror> <!--This sends everything else to /public --> <id>nexus</id> <mirrorOf>external:*</mirrorOf> <url>http://localhost:8081/nexus/content/groups/public</url> </mirror> </mirrors> <profiles> <profile> <id>nexus</id> <!--Enable snapshots for the built in central repo to direct --> <!--all requests to nexus via the mirror --> <repositories> <repository> <id>central</id> <url>http://central</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>true</enabled></snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>central</id> <url>http://central</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>true</enabled></snapshots> </pluginRepository> </pluginRepositories> </profile> </profiles> <activeProfiles> <!--make the profile active all the time --> <activeProfile>nexus</activeProfile> </activeProfiles> </settings>

29. Industrialisation des développements

30. Industrialisez ! Partagez vos livrables : Référentiels d’artifacts Partagez vos extensions Maven : Plugins Partagez le paramétrage Maven : POM Parent

31. Industrialisez ! Partagez vos versions recommandées d’artifacts : POM de dependencyManagement Scope import Partagez vos modèles d’applications : Archetypes Automatisez votre processus de release

32. Industrialisez ! Mettez en place une démarche de tests Tout l’outillage est pré-intégré : Junit, TestNG – tests unitaires, Selenium, Canoo – tests d’IHM, Fitnesse, Greenpepper – tests fonctionnels, SoapUI – tests d’intégration WS Et bien d’autres encore

33. Industrialisez ! Mettez en place une démarche qualité Uniformisation du code (CheckStyle) Recherche de mauvaises pratiques ou de bugs potentiels (PMD, FindBugs, Clirr) Couverture du code par les tests (Cobertura, Clover) Contrôles le build ne passe pas si certains critères ne sont pas atteints (Non compatibilité ascendante des APIs, …) Reporting Site web ou serveur dédié (sonar)

34. Sonar

35. Industrialisez ! Mettez en place un serveur d’intégration continue Environnement neutre Réagir au plus tôt intégration, tests, contrôles qualité Amélioration de la productivité et de la qualité Différents produits gratuits ou non Hudson, Bamboo, TeamCity, Continuum, Cruisecontrol, …

36. Hudson

37. Programme Faire le choix Maven Mettre en place Maven Utiliser Maven au jour le jour Structurer son projet Structurer son POM Pratiques de développement Apprendre Maven L’avenir de Maven

38. Structurer son projet

39. Structurer son projet A ne pas faire : Ne pas utiliser les conventions Sauf si migration, et uniquement en période transitoire. Avoir plusieurs sous modules avec des versions différentes Ces modules sont alors de véritables projets indépendants. Pas besoin d’un build global.

40. Structurer son projet A ne pas faire : Avoir un trop grand nombre de modules dans un même projet Est ce justifié par des contraintes ou besoins techniques ? Cela pénalise les performances le projet. Avoir un trop grand nombre d’héritage Cela complexifie la maintenance des POMs A quel endroit est positionné la configuration du plugin XXX ?

41. Structurer son projet A faire : Utiliser l’héritage « naturel » : Le reactor sert de parent ses sous-modules. Simplifie la configuration (site, scm, …)

42. Structurer son POM

43. Structurer son POM A ne pas faire : Dépendances : Confondre dependencies / dependencyManagement Plugins : Confondre plugins / pluginManagement Utiliser massivement le plugin AntRun Ne pas définir explicitement les versions de TOUS les plugins utilisés par le projet

44. Structurer son POM A ne pas faire : Profils : Se rendre dépendant de l’environnement Avoir des dépendances non définies par défaut Reporting et qualité Activer sur un code existant tous les rapportspossibles avec leurs configurations par défaut Faire des contrôles sur le formattage du code sans fournir la configuration associée pour l’IDE Mettre tout ce qu’il est possible de mettre dans le POM.

45. Structurer son POM A faire : Fixer les versions des dépendances dans le dependencyManagement de plus haut niveau dans l’héritage du projet Définir les dépendances (groupId, artifactId, scope) au plus prêt de leur utilisation (dans les modules) Utiliser les plugins dependency (apache) et versions (mojo) pour analyser et maintenir les dépendances de votre projet

46. Pratiques de développement

47. Pratiques de développement A ne pas faire : Passer son temps dans la console, S’échanger des jars par mail, Utiliser systématiquement &quot;-Dmaven.test.skip=true » Faire les releases à la main

48. Pratiques de développement A faire : Tenir sa version de Maven à jour On a pu noter sur la version 2.1 une réduction de plus 75% du temps de résolution des modules et dépendances d’un projet Utiliser le plugin reactor (ou Maven >= 2.1) pour ne reconstruire que ce qui est nécessaire Adapter son utilisation de Maven à son IDE.

49. Programme Faire le choix Maven Mettre en place Maven Utiliser Maven au jour le jour Apprendre Maven Où trouver des documentations ? Quels ouvrages sont disponibles ? Où trouver du support ? L’avenir de Maven

50. Où trouver des documentations ?

51. Documentations Le site web : http://maven.apache.org Le wiki projet : http://docs.codehaus.org/display/MAVEN Le wiki utilisateurs : http://docs.codehaus.org/display/MAVENUSER

52. Quels ouvrages sont disponibles ?

53. Ouvrages Sonatype / O’Reilly : The Definitive Guide http://www.sonatype.com/books Gratuit en version électronique D’ici la fin de l’année (?) en français

54. Ouvrages Exist Global Better builds with Maven http://www.maestrodev.com/better-build-maven Gratuit Version électronique uniquement

55. Ouvrages Nicolas De Loof – Arnaud Héritier / Pearson Un ouvrage original axé sur la pratique En français D’ici la fin de l’année

56. Ouvrages OCTO Technology Java Productivity Primer 12 pratiques autour de Maven et des usines de développement pour améliorer le productivité en Java http://www.octo.com Gratuit En français cet été (enfin !!)

57. Où trouver du support ?

58. Support Listes de diffusion http://maven.apache.org/mail-lists.html IRC irc.codehaus.org - #maven Developpez.net http://www.developpez.net/ forum maven En français Contrats de support Sonatype et quelques autres entreprises

59. Programme Faire le choix Maven Mettre en place Maven Utiliser Maven au jour le jour Apprendre Maven L’avenir de Maven Le produit La concurrence La communauté

60. Le produit

61. Apache Maven 2.0.x Maintenance corrective Dernière version publiée : 2.0.10 Pas certain qu’une version 2.0.11 voit le jour.

62. Apache Maven 2.x Maintenance évolutive Corrections qui imposent un refactoring conséquent Dernière version publiée : 2.1.0 La version 2.2.0 sera bientôt disponible 2.2.0-RC3 déjà disponible Correction du problème de résolution des propriétés et de transformation du POM apparus en 2.1.0 Java 5 en pré-requis pour exécuter Maven

63. Apache Maven 3.x N’AYEZ PAS PEUR, NE FUYEZ PAS !!! Notre objectif : Compatibilité avec Maven 2.x assurée Pour les projets Pour les plugins

64. Apache Maven 3.x Pourquoi une 3.x ? Parce que refonte importante du code Réduction / Désendettement du code Refonte de l’API d’utilisation (embedder) pour une meilleure intégration aux IDEs

65. Apache Maven 3.x Refonte de la gestion des artifacts (Mercury) Amélioration de l’algorithme de résolution des dépendances (SAT), Abstraction des référentiels, Gestion des versions configurable (Maven vs OSGI vs …), Réécriture de la couche de transport http/webdav par l’équipe de Jetty. Cycle de vie prédictible et interrogeable,

66. Apache Maven 3.x Abstraction du descripteur de projet Gestion de plusieurs versions du POM Gestion de plusieurs formats du POM Comment gérer la compatibilité avec les anciennes versions de Maven ? Remplacement de plexus par une implémentation « standard « (JSR 299 ou JSR 330) : Guice ? XBR ? ...

67. La concurrence

68. Les concurrents Ant + Ivy, Easy Ant, Gant, Graddle, … Offrent la souplesse d’un outillage scriptable Cherchent à apporter un niveau de service proche de Maven (gestion de dépendances, ..) mais avec une standardisation moins contraignante. Cette souplesse ne leur sera t’elle pas fatale comme pour Maven 1 ?

69. La communauté

70. La communauté des utilisateurs 1780 inscrits sur la liste de diffusion des utilisateurs Statistiques sur 90 jours En bleu le nombre d’inscrits En rouge le nombre de messages par jours

71. Le site web

72. Les téléchargements Nombre de téléchargements par mois depuis un an

73. L’équipe projet Plus de 60 committeurs enregistrés, Plus de 20 actifs depuis le début de l’année, Des entreprises comme Sonatype fournissent des ressources pour le projet et du support professionnel pour les utilisateurs, Une communauté de développeurs moins isolée : rapprochements avec Eclipse, Jetty, …

74. Conclusion Aujourd’hui très largement adopté par les entreprises, Un produit avec une grande valeur ajoutée, Une communauté d’utilisateurs et de développeurs active, Du support professionnel, Une produit loin d’être « parfait », Encore beaucoup de choses à faire, Mais un véritable challenge à relever Venez nous aider à le réaliser !!

75. Questions ?

76. Licence Les photos et logos appartiennent à leurs auteurs respectifs Le contenu de la présentation est sous licence Creative Commons 2.0 France Contrat Paternité Pas d'Utilisation Commerciale Partage des Conditions Initiales à l'Identique http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

77. Buffet Merci pour votre attention Merci à Sopra Group pour son sponsoring