soiree maven 2

74
Maven2 Maven2 Nicolas De loof

Upload: laurent-ruaud

Post on 22-Dec-2014

834 views

Category:

Technology


3 download

DESCRIPTION

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.

TRANSCRIPT

Maven2 Maven2

Nicolas De loof

Qui suis-je ?

Nicolas De loof Software Architect , 10 ans de Committer Maven depuis fin 2007plugins JavaScript et GWTApache Commons-monitoring

Fondateur du

http://blog.loof.fr

Prologue

Constat

Y’a toujours des problèmes

Erreur dans la configurationOubli d’une dépendanceOubli d’un fichierCorrection de dernière minute qui introduit une régression…Pourtant ça marche sur mon poste !Elle est où la doc ?

etc

Prologue

Génération des binaires

Distribution

Qualimétrie

Documentation

Configuration IDE

Génération de code

Gestion de version?

Prologue

Apache Ant

Mutualisation d’un projet à l’autre…copier/collerProperties, properties, et encore properties

Réutilisation …Fusion de scripts d’origines différentes

Prologue

Maven 1 = scripts Ant mutualisés (« plugins ») outillés par des tags Jelly

Dérive progressive comme langage de ScriptInvocations inter-plugins … cyclesMutualisation ?

Prologue

Prendre les bonnes idées de Maven 1

… sans les faiblesses

Maven2 … c’est quoi ?

Quelques règles de structureUn moteur d’exécution de plugins

… et rien d’autre !

Et surtout pas un N-ième langage de script !

Conventions…

Maven établit des conventions « raisonnables » sur la structure du projet :

Sources dans srcLivrables dans src/mainTests dans src/testTout ce qui est construit dans targetCode généré dans target/generated-sources …

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

exemple

<?xml version="1.0" encoding="UTF-8"?><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>

Plugin

Ecrit en JavaProjet « maven » à part entièrePeut exploiter toute librairie java jugée utileConfiguré par Injection de dépendancesExécution 100% « étanche » : indépendant du projet et des autres plugins

Cycle de vie

Validategenerate-sources

generate-resourcesprocess-resources

compileprocess-classes

test-compiletest

packageintegration-test

verifyinstall deploy

phases

plugins

resource:resource

compiler:compile

surefire:test

jar:jar

install:install

deploy:deploy

Cycle de vie

Validategenerate-sources

generate-resourcesprocess-resources

compileprocess-classes

test-compiletest

packageintegration-test

verifyinstall deploy

phases

plugins

resource:resource

compiler:compile

surefire:test

jar:jar

install:install

deploy:deploy

cxf:wsdl2java

Cycle de vie

Validategenerate-sources

generate-resourcesprocess-resources

compileprocess-classes

test-compiletest

packageintegration-test

verifyinstall deploy

phases

plugins

resource:resource

compiler:compile

surefire:test

jar:jar

install:install

deploy:deploy

cxf:wsdl2java

[email protected]

Modèle du projet

Validategenerate-sources

generate-resourcesprocess-resources

compileprocess-classes

test-compiletest

packageintegration-test

verifyinstall deploy

phases MavenProjec

taddSourceRoot

getSourceRoots

plugins

resource:resource

compiler:compile

surefire:test

jar:jar

install:install

deploy:deploy

cxf:wsdl2java

[email protected]

toujours plus

Il est aisé d’ajouter un plugin

Outillage de testContrôle qualitéGénération de codePackaging spécifique…

SANS impact sur l’existant

Plugins : qui ? où ?

Plugins « officiels » : http://maven.apache.org/plugins/Plugins « communautaires » : http://mojo.codehaus.org/Plugins spécifiquescxf, jaxws, cargo, …

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èretoutes les librairies sont accessiblesle plugin peut être outillé de testsMécanisme de documentation intégréLa diffusion/mutualisation du plugin est facilitée

Dépendances

Maven gère les dépendances nécessaire au projet

sans Maven avec Maven

Transitivité

Mon projet dépend d’HibernateHibernate dépend d’ EHcache

Donc Mon projet dépend d’ EHcache

Transitivité

Vous sauriez gérer ça à la main ?

Effet de bord

Maven encourage les librairies ciblées plutôt que le gros JAR qui fait tout

Plus de librairiesGestion fine des dépendances

Repository

= Dépôt de librairiesDé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

Repository

Scopes

CompileUtilisé pour compiler src/main/java

RuntimeNécessaire à l’exécution mais non référencé

(ex : driver JDBC)

TestUtilisé pour compiler et exécuter les tests

ProvidedUtilisé par compiler mais doit être fournit par l’environnement (• JEE)

Transitivité

Mon projet dépend d’HibernateHibernate dépend d’ EHcache

Donc Mon projet dépend d’ EHcache

SNAPSHOTS

<plugin><groupId>org.codehaus.mojo</groupId><artifactId>gwt-maven-plugin</artifactId><version>1.0-SNAPSHOT</version><executions><execution><goals><goal>eclipse</goal><goal>compile</goal><goal>generateAsync</goal></goals></execution></executions><configuration>…</configuration></plugin>

<version>2.5.2-20080520.120258-2</version>

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>

Repository d’entreprise

Héritage

Mettre en commun la configuration MavenConfiguration des pluginsDépendances communesInfrastructure commune

Fixer les versionsVersions des plugins <versionManagement>Versions des dépendances <dependencyManagement>

Modules

« Diviser pour régner »Décomposer le projet en modules

Par domaine fonctionnelPar technologieGestion précise des dépendancesRespect des règles d’architecture

Un projet POM pour enchaîner les modules

Modules + héritage

« Héritage naturel »POM racine

Configuration globale du projet

ModulesHéritent du POM racine

Héritage global

« Corporate POM »

Configuration globale « entreprise »Outils Q&AConfiguration par défaut des pluginsInfrastructure Versions de référence (scope « import »)

Profils

Spécialiser le buildProfil « fast »Profil « dev »Profil « ci »Profil « release »

ActivationÀ la demande -PxxxSur critère (OS, fichier, propriété « -D », …)

Q.A.

Site et raportsDocumentation (projet, javadoc, XRef)Résultat de l’exécution des tests Couverture de tests : clover, cobertura, emmaQualité du code : findbugsConformité aux standards : checkstylePatterns / Antipatterns : pmd…

Intégration continue

Une seule commande [ + un profil ]

POM.xml

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

POM.xml

<dependency><groupId>org.codehaus.plexus</groupId><artifactId>plexus-archiver</artifactId><version>1.0-alpha-9</version><exclusions><exclusion><groupId>org.codehaus.plexus</groupId><artifactId>plexus-container-default</artifactId></exclusion><exclusion><groupId>org.codehaus.plexus</groupId><artifactId>plexus-component-api</artifactId></exclusion></exclusions></dependency>

<dependencygroupId="org.codehaus.plexus"artifactId="plexus-archiver"version="1.0-alpha-9"><exclusion>org.codehaus.plexus:plexus-container-default</exclusion><exclusion>org.codehaus.plexus:plexus-component-api</exclusion></dependency>

POM.xml

<plugin><groupId>org.codehaus.mojo</groupId><artifactId>xml-maven-plugin</artifactId><version>1.0-beta-2</version><executions><execution><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>...

<plugin groupId="org.codehaus.mojo" artifactId="xml-maven-plugin" version="1.0-beta-2"><execution phase="generate-sources" goal="transform" /><configuration><transformationSet dir="src/main/wsdl"><include>adg.wsdl</include></transformationSet>...

Support des IDE ?

Netbeans : IntelliJ IDEA : Eclipse : … en progrès

Sondage : quel IDE utilisez vous ?

Release often ?

Peu de développeurs+

Politique frileuse Apache+

Mécanisme de SNAPSHOTS=

Les releases de plugin sont rares

Plugins absents

De nombreux outils n’ont toujours pas de plugin maven2

La faute du plugin AntRun ?La faute de l’API Maven ?

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 ?

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

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

Version Java cible

XYZ.jar est-il compatible java 1.4 ?Le plugin YY nécessite Java5Maven nécessite Java 1.4Mon projet cible Java 1.3

Doublons

commons-beanutils + commons-beanutils-corecommons-logging + commons-logging-apicommons-io + org.apache.commons:-io…

Exclusion globale

Je ne VEUX PAS utiliser commons-logging !

Astuce « common-logging:99.0 »

Tests d’intégration

src/it/java ?Phase « Integration-test » ?Projet dédié ?

Interrogations

OSGi Java Modules (JSR 277)POM.xml

… quelle place pour maven ?

Interrogations

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

Conflits d’intérêts

Conséquences

Repository d’entreprise : Archiva vs Nexus

Intégration sous Eclipse : q4e (iam) vs m2eclispe

Techno-obscur

Injection de dépendances : PlexusSéparation des classloaders : ClassWorldsMapping Java / XML : Modello

• Trois projets clés, hors fondation apache

Sondage : qui connaît au moins un de ces outils ?

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.

Un gars, une vision

Rod Jonhson • Spring

Marc Fleury • JBoss

Jason Van Zyl • Maven 3

épilogue

« Killer » plugin : Release

Génération du livrable du projet ?

Option 1 : MaProcédureDe50PagesJamaisAJour.docOption 2 :mvn release:prepare mvn release:perform

« 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-projectmvn archetype:generate

Bonnes pratiques

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 "-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

Bonnes pratiques

Adapter le projet à Maven, pas l’inverseUtiliser des modules ciblés et simplePenser « plugin »Participer à la communauté des utilisateursRapporter ses problèmes en utilisant un cas de test simple

Bonnes pratiques

Verrouiller les versions des pluginsIndiquer les dépendances directesLire 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 "-Dmaven.test.skip=true"

Bonnes pratiques

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

Docs utiles

Question / réponses