Soiree Maven 2

1 107 vues

Publié le

Outil de construction de projet adoré par certain, décrié par d'autres, que peut apporter Maven à vos projets ? Dans cette présentation pratique et sans angélisme, les points forts et les faiblesses de Maven ont été abordés. En marge de la présentation, Nicolas a présenté quelques bonnes pratiques à mettre en place sur les projets.

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 107
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
40
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Soiree Maven 2

  1. 1. Maven2 Nicolas De loof
  2. 2. Qui suis-je ? Nicolas De loof Software Architect , 10 ans de Committer Maven depuis fin 2007 plugins JavaScript et GWT Apache Commons-monitoring Fondateur du http://blog.loof.fr
  3. 3. Prologue
  4. 4. Constat 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… Pourtant ça marche sur mon poste ! Elle est où la doc ? etc
  5. 5. Prologue Génération des binaires Génération de code Distribution Documentation ? Qualimétrie Gestion de version Configuration IDE
  6. 6. Prologue Apache Ant Mutualisation d’un projet à l’autre… copier/coller Properties, properties, et encore properties Réutilisation … Fusion de scripts d’origines différentes
  7. 7. Prologue Maven 1 = scripts Ant mutualisés (« plugins ») outillés par des tags Jelly Dérive progressive comme langage de Script Invocations inter-plugins … cycles Mutualisation ?
  8. 8. Prologue Prendre les bonnes idées de Maven 1 … sans les faiblesses
  9. 9. Maven2 … c’est quoi ? Quelques règles de structure Un moteur d’exécution de plugins … et rien d’autre ! Et surtout pas un N-ième langage de script !
  10. 10. Conventions… Maven établit des conventions « raisonnables » sur la structure du projet : Sources dans src Livrables dans src/main Tests dans src/test Tout ce qui est construit dans target Code généré dans target/generated-sources …
  11. 11. … over configuration Conventions = moins de configuration pour chaque plugin Plus d’homogénéité entre projets Un projet « basique » peut être compilé, testé, packagé, diffusé par maven sans configuration spécifique.
  12. 12. exemple <?xml version=quot;1.0quot; encoding=quot;UTF-8quot; ?> <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany</groupId> <artifactId>foo</artifactId> <version>1.0.0</version> <dependencies> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.12</version> </dependency> </dependencies> <build> </build> </project>
  13. 13. Plugin Ecrit en Java Projet « maven » à part entière Peut exploiter toute librairie java jugée utile Configuré par Injection de dépendances Exécution 100% « étanche » : indépendant du projet et des autres plugins
  14. 14. Cycle de vie phase plugin s s Validate generate-sources resource:resource generate-resources process-resources compiler:compile compile process-classes surefire:test test-compile test package jar:jar integration-test install:install verify install deploy deploy:deploy
  15. 15. Cycle de vie phase plugin s s Validate cxf:wsdl2java generate-sources resource:resource generate-resources process-resources compiler:compile compile process-classes surefire:test test-compile test package jar:jar integration-test install:install verify install deploy deploy:deploy
  16. 16. Cycle de vie phase plugin s s Validate cxf:wsdl2java generate-sources resource:resource generate-resources process-resources compiler:compile compile process-classes team@breizhjug.org surefire:test test-compile test package jar:jar integration-test install:install verify install deploy deploy:deploy
  17. 17. Modèle du projet phase plugin MavenProjec s s Validate t cxf:wsdl2java generate-sources addSourceRoot resource:resource generate-resources process-resources compiler:compile compile getSourceRoots process-classes team@breizhjug.org surefire:test test-compile test package jar:jar integration-test install:install verify install deploy deploy:deploy
  18. 18. toujours plus Il est aisé d’ajouter un plugin Outillage de test Contrôle qualité Génération de code Packaging spécifique … SANS impact sur l’existant
  19. 19. Plugins : qui ? où ? Plugins « officiels » : http://maven.apache. org/plugins/ Plugins « communautaires » : http://mojo. codehaus.org/ Plugins spécifiques cxf, jaxws, cargo, …
  20. 20. Besoin spécifique ? L’écriture d’un plugin est facile (plus que celle d’une tâche ANT) En Java, Groovy, BeanShell … Projet Java/Maven à part entière toutes les librairies sont accessibles le plugin peut être outillé de tests Mécanisme de documentation intégré La diffusion/mutualisation du plugin est facilitée
  21. 21. Dépendances Maven gère les dépendances nécessaire au projet sans Maven avec Maven
  22. 22. Transitivité Mon projet dépend d’Hibernate Hibernate dépend d’ EHcache Donc Mon projet dépend d’ EHcache
  23. 23. Transitivité Vous sauriez gérer ça à la main ?
  24. 24. Effet de bord Maven encourage les librairies ciblées plutôt que le gros JAR qui fait tout Plus de librairies Gestion fine des dépendances
  25. 25. Repository = Dépôt de librairies Dépôt local ($HOME/.m2/repository) Évite la multiplication des .jar sur le poste de dev. Dépôt(s) public(s) (http://repo1.maven. org/maven2) Mise à disposition rapide des librairies libres Dépôt privé Gestion fine des librairies, libres ou non
  26. 26. Repository
  27. 27. Scopes Compile Utilisé pour compiler src/main/java Runtime Nécessaire à l’exécution mais non référencé (ex : driver JDBC) Test Utilisé pour compiler et exécuter les tests Provided Utilisé par compiler mais doit être fournit par l’ environnement (• JEE)
  28. 28. Transitivité Mon projet dépend d’Hibernate Hibernate dépend d’ EHcache Donc Mon projet dépend d’ EHcache
  29. 29. SNAPSHOTS <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>gwt-maven-plugin</artifactId> <version>2.5.2-20080520.120258- <version>1.0-SNAPSHOT</version> 2</version> <executions> <execution> <goals> <goal>eclipse</goal> <goal>compile</goal> <goal>generateAsync</goal> </goals> </execution> </executions> <configuration> … </configuration> </plugin>
  30. 30. Deploiement <distributionManagement> <repository> <id>sourceforge</id> <name>sync to central</name> <url>scp://shell.sourceforge.net/…</url> </repository> <snapshotRepository> <id>sourceforge</id> <name>snapshot repository</name> <uniqueVersion>false</uniqueVersion> <url>scp://shell.sourceforge.net/…</url> </snapshotRepository> </distributionManagement>
  31. 31. Repository d’entreprise
  32. 32. Héritage Mettre en commun la configuration Maven Configuration des plugins Dépendances communes Infrastructure commune Fixer les versions Versions des plugins <versionManagement> Versions des dépendances <dependencyManagement>
  33. 33. Modules « Diviser pour régner » Décomposer le projet en modules Par domaine fonctionnel Par technologie Gestion précise des dépendances Respect des règles d’architecture Un projet POM pour enchaîner les modules
  34. 34. Modules + héritage « Héritage naturel » POM racine Configuration globale du projet Modules Héritent du POM racine
  35. 35. Héritage global « Corporate POM » Configuration globale « entreprise » Outils Q&A Configuration par défaut des plugins Infrastructure Versions de référence (scope « import »)
  36. 36. Profils Spécialiser le build Profil « fast » Profil « dev » Profil « ci » Profil « release » Activation À la demande -Pxxx Sur critère (OS, fichier, propriété « -D », …)
  37. 37. Q.A. Site et raports Documentation (projet, javadoc, XRef) Résultat de l’exécution des tests Couverture de tests : clover, cobertura, emma Qualité du code : findbugs Conformité aux standards : checkstyle Patterns / Antipatterns : pmd …
  38. 38. Intégration continue Une seule commande [ + un profil ]
  39. 39. POM.xml Formalisme XML incroyablement verbeux .. et désormais intouchable pour rester compatible
  40. 40. POM.xml <dependency <dependency> groupId=quot;org.codehaus.plexusquot; <groupId>org.codehaus.plexus</groupId> artifactId=quot;plexus-archiverquot; <artifactId>plexus-archiver</artifactId> version=quot;1.0-alpha-9quot;> <version>1.0-alpha-9</version> <exclusion> <exclusions> org.codehaus.plexus:plexus-container-default <exclusion> </exclusion> <groupId>org.codehaus.plexus</groupId> <exclusion> <artifactId>plexus-container-default</artifactId> org.codehaus.plexus:plexus-component-api </exclusion> </exclusion> <exclusion> </dependency> <groupId>org.codehaus.plexus</groupId> <artifactId>plexus-component-api</artifactId> </exclusion> </exclusions> </dependency>
  41. 41. POM.xml <plugin <plugin>groupId=quot;org.codehaus.mojoquot; artifactId=quot;xml-maven-pluginquot; version=quot; 1.0-beta-2quot;> <groupId>org.codehaus.mojo</groupId> <execution phase=quot;generate-sourcesquot; goal=quot;transformquot; /> <artifactId>xml-maven-plugin</artifactId> <configuration> <version>1.0-beta-2</version> <transformationSet dir=quot;src/main/wsdlquot;> <executions> <include>adg.wsdl</include> <execution> </transformationSet> <goals> ... <goal>transform</goal> </goals> <phase>generate-sources</phase> </execution> </executions> <configuration> <transformationSets> <transformationSet> <dir>src/main/wsdl</dir> <includes> <include>adg.wsdl</include> </includes> ...
  42. 42. Support des IDE ? Netbeans : IntelliJ IDEA : Eclipse : … en progrès Sondage : quel IDE utilisez vous ?
  43. 43. Release often ? Peu de développeurs + Politique frileuse Apache + Mécanisme de SNAPSHOTS = Les releases de plugin sont rares
  44. 44. Plugins absents De nombreux outils n’ont toujours pas de plugin maven2 La faute du plugin AntRun ? La faute de l’API Maven ?
  45. 45. Plugins redondants Ex : plugins XML et XSLT chez « Mojo » Plugin GWT « draft » initial sous Mojo code.google.com/p/gwt-maven 3 propositions +ou- abouties dans le JIRA Mojo = fusion (ouf) Statut d’un plugin ? Réactivité ? Moteur de recherche ?
  46. 46. Transitivité De nombreux projets déclarent des dépendances superflues / incorrectes Règle : un POM.xml publié n’est jamais modifié Les choses s’améliorent… Utiliser un dépôt privé !
  47. 47. JAR javax.* absents Pour raison de licence ! Mais qui s’en soucie à part la fondation Apache ? Pourquoi pas un « accept licence ? [Y/N] » ? Dépôt sur java.net pour les APIs récentes
  48. 48. Version Java cible XYZ.jar est-il compatible java 1.4 ? Le plugin YY nécessite Java5 Maven nécessite Java 1.4 Mon projet cible Java 1.3
  49. 49. Doublons commons-beanutils + commons-beanutils-core commons-logging + commons-logging-api commons-io + org.apache.commons:-io …
  50. 50. Exclusion globale Je ne VEUX PAS utiliser commons-logging ! Astuce « common-logging:99.0 »
  51. 51. Tests d’intégration src/it/java ? Phase « Integration-test » ? Projet dédié ?
  52. 52. Interrogations OSGi Java Modules (JSR 277) POM.xml … quelle place pour maven ?
  53. 53. Interrogations Plus généralement, quelle est la roadmap ? Maven 2.2, 2.3 Maven 3 ???
  54. 54. Conflits d’intérêts
  55. 55. Conséquences Repository d’entreprise : Archiva vs Nexus Intégration sous Eclipse : q4e (iam) vs m2eclispe …
  56. 56. Techno-obscur Injection de dépendances : Plexus Séparation des classloaders : ClassWorlds Mapping Java / XML : Modello • Trois projets clés, hors fondation apache Sondage : qui connaît au moins un de ces outils ?
  57. 57. Community-driven ? Théoriquement, le développement est « piloté par la communauté » Et dans les faits ? Re: [M2] Are pom.xml settings.xml really well-formed? by Jason van Zyl – Feb 09, 2008; 06:09pm We don't use Xerces, never have, never will. Re: [M2] Maven core : Plexus vs Spring / OSGi ? by Jason van Zyl – May 02, 2008; 05:53&m As far as Spring, that's honestly never going to happen while I'm here because I will always argue that something like XBR/Guice which is a DI library is more appropriate and there is nothing Spring can do that XBR cannot do today in terms of dependency injection.
  58. 58. Un gars, une vision Rod Jonhson • Spring Marc Fleury • JBoss Jason Van Zyl • Maven 3
  59. 59. épilogue
  60. 60. « Killer » plugin : Release Génération du livrable du projet ? Option 1 : MaProcédureDe50PagesJamaisAJour.doc Option 2 : mvn release:prepare mvn release:perform
  61. 61. « Killer » plugin : Archetype Démarrer un projet « propre » en 2 minutes ? En se basant sur un projet de référence ! mvn archetype:create-from-project mvn archetype:generate
  62. 62. Bonnes pratiques
  63. 63. Mauvaises pratiques 1. Ne pas utiliser les conventions 2. Mettre tout ce qui est possible de mettre dans le pom 3. Se rendre dépendant de l’environnement 4. Multiplier les niveaux d’héritage 5. Utiliser systématiquement quot;-Dmaven.test.skip=true » 6. Faire les releases à la main 7. S’échanger les jars par mail 8. Utilisation massive du plugin antrun 9. Confondre dependencies et dependencyManagement 10. Rester le nez dans la console
  64. 64. Bonnes pratiques Adapter le projet à Maven, pas l’inverse Utiliser des modules ciblés et simple Penser « plugin » Participer à la communauté des utilisateurs Rapporter ses problèmes en utilisant un cas de test simple
  65. 65. Bonnes pratiques Verrouiller les versions des plugins Indiquer les dépendances directes Lire la doc ;-) [2 « open-books »] Utiliser un gestionnaire de dépôt (archiva/nexus) Rester indépendant de l’environnement … éviter les settings.xml exotiques Attention au quot;-Dmaven.test.skip=truequot;
  66. 66. Bonnes pratiques « Les meilleures pratiques sont celles qui correspondent à vos besoins »
  67. 67. Docs utiles
  68. 68. Question / réponses

×