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.

1. Maven2
Nicolas De loof

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. Prologue

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. Prologue
Génération des binaires
Génération de code
Distribution
Documentation
?
Qualimétrie Gestion de version
Configuration IDE

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. 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. Prologue
Prendre les bonnes idées de Maven 1
… sans les faiblesses

10. 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 !

11. 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
…

12. … 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.

13. 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>

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. Plugins : qui ? où ?
Plugins « officiels » : http://maven.apache.
org/plugins/
Plugins « communautaires » : http://mojo.
codehaus.org/
Plugins spécifiques
cxf, jaxws, cargo, …

21. 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

22. Dépendances
Maven gère les dépendances nécessaire au
projet
sans Maven avec Maven

23. Transitivité
Mon projet dépend d’Hibernate
Hibernate dépend d’ EHcache
Donc Mon projet dépend d’ EHcache

24. Transitivité
Vous sauriez gérer ça à la main ?

25. 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

26. 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

27. Repository

28. 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)

29. Transitivité
Mon projet dépend d’Hibernate
Hibernate dépend d’ EHcache
Donc Mon projet dépend d’ EHcache

30. 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>

31. 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>

32. Repository d’entreprise

33. 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>

34. 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

35. Modules + héritage
« Héritage naturel »
POM racine
Configuration globale du projet
Modules
Héritent du POM racine

36. 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 »)

37. 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 », …)

38. 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
…

39. Intégration continue
Une seule commande [ + un profil ]

41. POM.xml
Formalisme XML incroyablement verbeux
.. et désormais intouchable pour rester compatible

42. 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>

43. 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>
...

44. Support des IDE ?
Netbeans :
IntelliJ IDEA :
Eclipse : … en progrès
Sondage : quel IDE utilisez vous ?

45. Release often ?
Peu de développeurs
+
Politique frileuse Apache
+
Mécanisme de SNAPSHOTS
=
Les releases de plugin sont rares

46. Plugins absents
De nombreux outils n’ont toujours pas de plugin
maven2
La faute du plugin AntRun ?
La faute de l’API Maven ?

47. 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 ?

48. 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é !

49. 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

50. 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

51. Doublons
commons-beanutils + commons-beanutils-core
commons-logging + commons-logging-api
commons-io + org.apache.commons:-io
…

52. Exclusion globale
Je ne VEUX PAS utiliser commons-logging !
Astuce « common-logging:99.0 »

53. Tests d’intégration
src/it/java ?
Phase « Integration-test » ?
Projet dédié ?

54. Interrogations
OSGi
Java Modules (JSR 277)
POM.xml
… quelle place pour maven ?

55. Interrogations
Plus généralement, quelle est la roadmap ?
Maven 2.2, 2.3
Maven 3 ???

57. Conflits d’intérêts

58. Conséquences
Repository d’entreprise : Archiva vs Nexus
Intégration sous Eclipse : q4e (iam) vs
m2eclispe
…

59. 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 ?

60. 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.

61. Un gars, une vision
Rod Jonhson • Spring
Marc Fleury • JBoss
Jason Van Zyl • Maven 3

63. épilogue

64. « Killer » plugin :
Release
Génération du livrable du projet ?
Option 1 :
MaProcédureDe50PagesJamaisAJour.doc
Option 2 :
mvn release:prepare
mvn release:perform

66. « 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

68. Bonnes pratiques

69. 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

70. 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

71. 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;

72. Bonnes pratiques
« Les meilleures pratiques sont celles qui
correspondent à vos besoins »

73. Docs utiles

74. Question / réponses