Maven on Jean-Christophe Gay

Utiliser une propriété unique comme version Maven

Fri, 02 Sep 2016 20:49:00 +0200

Quand je travaille sur un projet Maven multi-modules (plusieurs dizaines) sur plusieurs branches en même temps, je me retrouve souvent avec des conflits à résoudre pour chaque merge sur les versions définies un peu partout dans les pom.xml… Et c’est tout sauf marrant.
Tour d’horizon des solutions pour réduire le nombre de <version> déclarées dans tous ces pom.xml.

Notre projet exemple de départ est donc constitué de deux modules :

.
├── pom.xml
├── submodule-1
│   └── pom.xml
└── submodule-2
    └── pom.xml

Le pom.xml du projet parent ressemble à :

<project>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>parent-pom</artifactId>
 <version>1.0-SNAPSHOT</version>
 <packaging>pom</packaging>

 <modules>
 <module>submodule-1</module>
 <module>submodule-2</module>
 </modules>
 
</project>

et ceux des modules :

<project>
 <parent>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>parent-pom</artifactId>
 <version>1.0-SNAPSHOT</version>
 </parent>

 <artifactId>submodule-1</artifactId>

</project>

La version du projet est répétée dans chaque pom.xml des modules, pour les changer ce n’est pas bien compliqué avec le plugin Versions. Par contre les merges entre branches sont vite pénibles, les conflits sont fréquents et généralement on ne peut pas se contenter de ne garder les changements que d’une des deux branches 😓.

Définir la version dans une propriété
#

Première tentative, extraire la version dans une propriété Maven. Le pom parent devient donc :

<project>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>parent-pom</artifactId>
 <version>${my-version}</version>
 <packaging>pom</packaging>

 <properties>
 <my-version>1.0-SNAPSHOT</my-version>
 </properties>

 <modules>
 <module>submodule-1</module>
 <module>submodule-2</module>
 </modules>

</project>

et un module utilise également la propriété ${my-version} pour référencer son parent :

<project>
 <parent>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>parent-pom</artifactId>
 <version>${my-version}</version>
 </parent>

 <artifactId>submodule-2</artifactId>

</project>

Etonnement ça fonctionne 😲
La seule arnaque provient des messages d’avertissements affichés par Maven.

Some problems were encountered while building the effective model for com.github.jcgay.example.version:submodule-1:jar:1.0-SNAPSHOT
'version' contains an expression but should be a constant. @ com.github.jcgay.example.version:parent-pom:${my-version}, /Users/jcgay/dev/toolbox-examples/unique-maven-version/pom.xml, line 7, column 14

Some problems were encountered while building the effective model for com.github.jcgay.example.version:submodule-2:jar:1.0-SNAPSHOT
'version' contains an expression but should be a constant. @ com.github.jcgay.example.version:parent-pom:${my-version}, /Users/jcgay/dev/toolbox-examples/unique-maven-version/pom.xml, line 7, column 14

Some problems were encountered while building the effective model for com.github.jcgay.example.version:parent-pom:pom:1.0-SNAPSHOT
'version' contains an expression but should be a constant. @ com.github.jcgay.example.version:parent-pom:${my-version}, /Users/jcgay/dev/toolbox-examples/unique-maven-version/pom.xml, line 7, column 14

It is highly recommended to fix these problems because they threaten the stability of your build.

For this reason, future Maven versions might no longer support building such malformed projects.

En l’état ce n’est pas vraiment sérieux, et puis il y a un autre problème avec cette solution mais on va la détailler dans la seconde.

Continuous delivery friendly version
#

Depuis Maven 3.2.1 il est possible d’utiliser des propriétés réservées pour éviter les messages d’avertissements précédents.

Si on remplace notre propriété my-version de la solution précédente par une autre nommée revision, plus de messages qui font peur 🎆.

Seulement utiliser des propriétés plutôt que des versions stables pose réellement un problème. Quand Maven installe dans le repository local ou déploie dans un repository distant nos artifacts, les pom.xml sont copiés en l’état. Si on a donc un projet qui dépend d’un de nos modules (comprendre qui n’est pas construit dans ce même projet multi-modules), la résolution des dépendances échouera car la propriété ${revision} n’existera pas dans ce projet extérieur.

Exemple avec ce projet tout simple qui n’est pas un module de notre parent-pom :

<project>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>independant-project</artifactId>
 <version>1.0-SNAPSHOT</version>
 
 <dependencies>
 <dependency>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>submodule-1</artifactId>
 <version>1.0-SNAPSHOT</version>
 </dependency>
 </dependencies>

</project>

Quand on lance un build :

$> mvn test

Scanning for projects...

Using the MultiThreadedBuilder implementation with a thread count of 4

------------------------------------------------------------------------
Building independant-project 1.0-SNAPSHOT
------------------------------------------------------------------------
Downloading: https://repo.maven.apache.org/maven2/com/github/jcgay/example/version/parent-pom/$%7Brevision%7D/parent-pom-$%7Brevision%7D.pom
------------------------------------------------------------------------
BUILD FAILURE
------------------------------------------------------------------------
Total time: 0.882 s (Wall Clock)
Finished at: 2016-08-09T15:26:09+02:00
Final Memory: 12M/193M
------------------------------------------------------------------------
Failed to execute goal on project independant-project: Could not resolve dependencies for project com.github.jcgay.example.version:independant-project:jar:1.0-SNAPSHOT: Failed to collect dependencies at com.github.jcgay.example.version:submodule-1:jar:1.0-SNAPSHOT: Failed to read artifact descriptor for com.github.jcgay.example.version:submodule-1:jar:1.0-SNAPSHOT: Could not find artifact com.github.jcgay.example.version:parent-pom:pom:${revision} in central (https://repo.maven.apache.org/maven2) -> [Help 1]

Et en effet le pom.xml présent dans mon repository local défini toujours ${revision} en tant que <version> du pom-parent.

Filtrer les pom à l’installation/déploiement
#

Ce problème de propriétés non remplacées m’a rappelé un vieil article dans lequel l’auteur s’était amusé à filtrer (dans le sens maven-resources-plugin filtering) ses fichiers pom.xml et les installer à la place des originaux.
J’ai donc recherché s’il était possible de faire de même mais avec une extension Maven (la dose de XML nécessaire et le côté gros hack de la solution décrite m’a découragé…). Et c’est effectivement faisable avec Aether (utilisé dans Maven depuis la version 3) via un org.eclipse.aether.impl.MetadataGenerator. On peut donc écrire un gros hack dans son langage préféré à la place 🤔.

Le code est disponible sur GitHub. Il prend la forme d’une extension Maven qui se charge de transformer les artifacts de type pom à l’installation et au déploiement. Toutes les occurrences de ${revision} sont remplacées par l’actuelle version de l’artifact traité (c’est à dire la valeur résolue de ${revision}). Le problème de résolution de dépendance est dans ce cas résolu !

On peut l’utiliser via le mécanisme d’extensions de Maven en créant (modifiant) le fichier ${maven.multiModuleProjectDirectory}/.mvn/extensions.xml :

<?xml version="1.0" encoding="UTF-8"?>
<extensions>
 <extension>
 <groupId>fr.jcgay.maven.extension</groupId>
 <artifactId>unique-revision-maven-filtering</artifactId>
 <version>[latest-version]</version>
 </extension>
</extensions>

ou bien en copiant directement le jar dans %M2_HOME%/lib/ext.

Conclusion
#

On a donc vu comment utiliser une propriété unique pour définir la version de tous les modules d’un projet. Clairement la fonctionnalité proposée par Maven (continuous delivery friendly version) ne semble pas prévue pour l’usage décrit ici, mais au moins je ne m’embête plus avec mes merge ! J’ai peut-être complètement raté une solution plus simple ? (dans ce cas je la veux bien 😉).

Déployer ses SNAPSHOT avec Travis CI

Wed, 29 Jul 2015 21:23:00 +0200

Mini guide pour déployer des binaires SNAPSHOT sur le repository OSS sonatype avec Travis CI.

Configuration de Maven
#

Il faut configurer Maven pour utiliser votre compte pour uploader des artifacts sur OSSRH.
Créer un fichier etc/deploy-settings.xml et utiliser des variables pour référencer vos identifiants :

<settings>
 <servers>
 <server>
 <id>ossrh</id>
 <username>${env.OSSRH_USER}</username>
 <password>${env.OSSRH_PASS}</password>
 </server>
 </servers>
</settings>

Ce fichier sera par la suite utilisé par mvn grâce à l’option --settings.

Identification
#

On a deux solutions pour stocker ses identifiants et les utiliser avec Travis CI.

Stockage dans les paramètres du repository
#

Dans les options de Travis CI https://travis-ci.org/user/repository/settings, on peut définir les variables d’environnements OSSRH_USER et OSSRH_PASS. Par défaut celles-ci seront masquées dans les logs.

Chiffrer ses identifiants
#

Il semble évident qu’on ne va pas sauvegarder ses identifiants en clair, Travis CI permet de chiffrer des données sensibles.

gem install travis

Et là on doit faire face à Ruby… Si vous ne développez pas dans cet eco-système, il y a des chances que celà se passe mal à partir de maintenant :( (en tout cas avec OS X)
Dans mon cas j’ai eu le droit à l’erreur suivante :

> gem install travis 
Fetching: multipart-post-2.0.0.gem (100%)
ERROR: While executing gem ... (Gem::FilePermissionError)
 You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory.

Le problème vient de la version installée par Apple, les utilisateurs de ruby utiliseront surement rvm, rbenv ou je ne sais quelle autre joyeuseté. Pour le commun des mortels qui ne veulent pas y passer une demi heure et qui n’ont pas envie de tout casser :

brew install ruby

Relancer un shell et l’installation du gem travis devrait mieux se passer…

On peut maintenant envoyer nos données importantes à travis :

travis encrypt --add -r jcgay/send-notification "OSSRH_USER='toto'"
travis encrypt --add -r jcgay/send-notification "OSSRH_PASS='s3cret&'"

Si les commandes sont lancées depuis le dossier qui contient le projet l’option -r n’est pas nécessaire et l’option --add ajoutera automatiquement les clefs cryptées dans le fichier .travis.yml.
jcgay/send-notification correspond bien entendu au projet pour lequel ont veut chiffrer des données.

Configuration de Travis CI
#

On veut déployer les SNAPSHOT sauf si Travis est en train de builder une pull-request. On peut pour cela utiliser la variable ${TRAVIS_PULL_REQUEST}.
La variable ${TRAVIS_TAG} permet de ne pas non plus déployer les releases (qui ne sont pas faites avec Travis dans mon cas).

On se retrouve donc avec les variables d’environnement cryptées au sein de .travis.yml :

env:
 global:
 - secure: GT8Hi5kgx2cLAGzh2ggZNTgiLm8J5fd64SYG3bkhgwZGbV/HRD8r8a1SYv1iQ72JqrDhlHQ7q8h17nDBFLjy99h/XKN4MacBu9CZhnPO7lXpuRefD3W/db6zWSk17a5DAKAt+1UOeyfohEkzx+JHcTfbvMg6hy+3DEPaVMUtV04=
 - secure: fQ4bSOcHWEURfsDQVhWA152GCiezQfh9YC45a2zae8oOk+6bIrHmrkJSyVYpUCLGdqO3Df+JTy6bfoqyJEsX7PkzGPZ10odSHw5qDqfTIolt7UympKtUvUNi6h5G6virGhBWjjs5REGjrgWdTlqKjNT2Ax/VlzNRskqaVAhEhl0=

et une étape de plus dans la section after_success:

after_success:
 - "[[ ${TRAVIS_PULL_REQUEST} == 'false' ]] && [[ ${TRAVIS_TAG} == '' ]] && mvn deploy -DskipTests --settings etc/deploy-settings.xml"

Et voilà tout roule !

Mesurer son temps de build Maven

Sun, 01 Feb 2015 20:07:00 +0200

Des outils pour mesurer en détail le temps de build de chaque exécution d’un build Maven.

Par défaut Maven ne mesure que le temps par module et total du build sans donner de temps intermédiaire.
Il existe heuresement des solutions pour obtenir les temps d’éxécutions de chaque étape de son build.

maven-profiler
#

Un outil que j’ai écris à l’époque car je n’en avais pas trouvé. Je m’en sers pour trouver quels étapes d’un build optimiser pour réduire son temps d’exécution.

Il génère un rapport (HTML ou JSON) archivé dans le dossier .profiler au sein du projet.

Pour l’installer il suffit de suivre les instructions disponibles sur github.

Le rapport est généré quand on lance un build avec la propriété système profile :

mvn install -Dprofile

Par défaut le rapport HTML est utilisé, pour avoir le modèle JSON :

mvn install -Dprofile -DprofileFormat=JSON

Exemple de rapport :

{
	"name": "maven-profiler",
 "goals": "clean install",
 "date": "2015/01/17 15:28:49",
	"parameters": "{profile=true, profileFormat=JSON}",
 "projects": [{
	 "project": "maven-profiler",
		"time": "6.793 s",
 	"mojos": [{
	 	"mojo": "org.apache.maven.plugins:maven-surefire-plugin:2.18:test {execution: default-test}",
		 "time": "2.512 s"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-shade-plugin:2.3:shade {execution: default}",
	 	"time": "1.458 s"
		}, {
 		"mojo": "org.codehaus.gmavenplus:gmavenplus-plugin:1.2:testCompile {execution: default}",
	 	"time": "818.3 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-compiler-plugin:3.2:compile {execution: default-compile}",
	 	"time": "538.7 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-source-plugin:2.4:jar-no-fork {execution: attach-sources}",
	 	"time": "248.5 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-jar-plugin:2.5:jar {execution: default-jar}",
	 	"time": "238.2 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-resources-plugin:2.7:resources {execution: default-resources}",
	 	"time": "171.7 ms"
 		}, {
 		"mojo": "org.codehaus.plexus:plexus-component-metadata:1.6:generate-metadata {execution: default}",
	 	"time": "170.5 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-enforcer-plugin:1.2:enforce {execution: enforce-maven}",
	 	"time": "126.0 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-clean-plugin:2.6.1:clean {execution: default-clean}",
	 	"time": "76.11 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-install-plugin:2.5.2:install {execution: default-install}",
	 	"time": "53.95 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-compiler-plugin:3.2:testCompile {execution: default-testCompile}",
	 	"time": "2.850 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-resources-plugin:2.7:testResources {execution: default-testResources}",
	 	"time": "2.518 ms"
	 }]
	}]
}

maven-timeline
#

Ce plugin présente les temps de construction de chaque phase au sein d’un build sous la forme d’un timeline. Initialement développé par David Gageot, il en existe un fork maintenu par l’équipe de takari.

Pour l’utiliser il fait ajouter une extension dans le fichier pom.xml :

<extension>
 <groupId>io.takari.maven</groupId>
 <artifactId>maven-timeline</artifactId>
 <version>1.6</version>
</extension>

Deux rapports sont générés, un en HTML et un en JSON.

{
 "start": "2015-02-01T19:18:18.738Z",
 "end": "2015-02-01T19:18:21.770Z",
 "dateTimeFormat": "iso8601",
 "events": [
 {
 "start": "2015-02-01T19:18:20.940Z",
 "end": "2015-02-01T19:18:21.095Z",
 "duration": 2380,
 "description": "com.github.jcgay.maven.color:maven-color-logback:package:jar:default-jar (2380 ms)",
 "trackNum": 1,
 "color": "blue",
 "durationEvent": true
 },
 {
 "start": "2015-02-01T19:18:19.136Z",
 "end": "2015-02-01T19:18:19.545Z",
 "duration": 830,
 "description": "com.github.jcgay.maven.color:maven-color-core:compile:compile:default-compile (830 ms)",
 "trackNum": 2,
 "color": "blue",
 "durationEvent": true
 },
 {
 "start": "2015-02-01T19:18:19.562Z",
 "end": "2015-02-01T19:18:19.564Z",
 "duration": 849,
 "description": "com.github.jcgay.maven.color:maven-color-agent:test-compile:testCompile:default-testCompile (849 ms)",
 "trackNum": 3,
 "color": "blue",
 "durationEvent": true
 },
 {
 "start": "2015-02-01T19:18:19.677Z",
 "end": "2015-02-01T19:18:19.818Z",
 "duration": 1103,
 "description": "com.github.jcgay.maven.color:maven-color-agent:package:jar:default-jar (1103 ms)",
 "trackNum": 3,
 "color": "blue",
 "durationEvent": true
 },
 
 ...
 
 {
 "start": "2015-02-01T19:18:20.801Z",
 "end": "2015-02-01T19:18:21.549Z",
 "duration": 2834,
 "description": "com.github.jcgay.maven.color:maven-color-log4j2:package:single:make-assembly (2834 ms)",
 "trackNum": 3,
 "color": "blue",
 "durationEvent": true
 }
 ]
}

tesla-profiler
#

Un autre profiler qui affiche les temps de build dans la console.

Le rapport est généré quand on lance un build avec la propriété système maven.profile :

mvn install -Dmaven.profile

Un exemple de résultat :

com.github.jcgay.maven:maven-profiler:2.2-SNAPSHOT

 clean 81ms
 org.apache.maven.plugins:maven-clean-plugin:2.6.1 (default-clean) 80ms

 validate 145ms
 org.apache.maven.plugins:maven-enforcer-plugin:1.2 (enforce-maven) 145ms

 process-resources 198ms
 org.apache.maven.plugins:maven-resources-plugin:2.7 (default-resources) 198ms

 compile 588ms
 org.apache.maven.plugins:maven-compiler-plugin:3.2 (default-compile) 588ms

 process-classes 209ms
 org.codehaus.plexus:plexus-component-metadata:1.6 (default) 209ms

 process-test-resources 3ms
 org.apache.maven.plugins:maven-resources-plugin:2.7 (default-testResources) 3ms

 test-compile 1s 2ms
 org.apache.maven.plugins:maven-compiler-plugin:3.2 (default-testCompile) 3ms
 org.codehaus.gmavenplus:gmavenplus-plugin:1.2 (default) 998ms

 test 2s 670ms
 org.apache.maven.plugins:maven-surefire-plugin:2.18 (default-test) 2s 669ms

 package 2s 778ms
 org.apache.maven.plugins:maven-jar-plugin:2.5 (default-jar) 250ms
 org.apache.maven.plugins:maven-source-plugin:2.4 (attach-sources) 270ms
 org.apache.maven.plugins:maven-shade-plugin:2.3 (default) 2s 258ms

Bon profiling !

Le cycle de vie de son build Maven

Sat, 22 Mar 2014 19:24:00 +0200

Avec Maven, je me suis souvent retrouvé un peu seul devant un POM en me demandant ce que pouvait bien exécuter mon build sans devoir aller lister toutes les exécutions déclarées. Depuis Maven 3 il est possible de prévoir ce qu’un build va exécuter au sein de son cycle de vie. Etrangement il n’y a rien qui permet d’afficher facilement ce plan de build calculé. Voici le buildplan-maven-plugin.

Configuration
#

Pour utiliser le plugin facilement, déclarer son groupId au sein de la configuration de Maven (ie settings.xml) :

<pluginGroups>
 <pluginGroup>fr.jcgay.maven.plugins</pluginGroup>
</pluginGroups>

Afficher le plan du build
#

Il est possible de lister toutes les exécutions de goals qui font parties du build. La simulation se déroule jusqu’à la phase deploy.

> mvn buildplan:list

[INFO] --- buildplan-maven-plugin:1.0:list (default-cli) @ buildplan-maven-plugin ---
[INFO] --------------------------------------------------------------------------------------------------------------------
[INFO] PLUGIN | PHASE | ID | GOAL
[INFO] --------------------------------------------------------------------------------------------------------------------
[INFO] maven-plugin-plugin | generate-sources | help-goal | helpmojo
[INFO] maven-plugin-plugin | process-classes | default-descriptor | descriptor
[INFO] maven-resources-plugin | process-resources | default-resources | resources
[INFO] maven-compiler-plugin | compile | default-compile | compile
[INFO] maven-plugin-plugin | process-classes | mojo-descriptor | descriptor
[INFO] maven-resources-plugin | process-test-resources | default-testResources | testResources
[INFO] maven-compiler-plugin | test-compile | default-testCompile | testCompile
[INFO] maven-surefire-plugin | test | default-test | test
[INFO] animal-sniffer-maven-plugin | process-classes | check-signature | check
[INFO] maven-jar-plugin | package | default-jar | jar
[INFO] maven-plugin-plugin | package | default-addPluginArtifactMetadata | addPluginArtifactMetadata
[INFO] maven-source-plugin | package | attach-sources | jar-no-fork
[INFO] license-maven-plugin | verify | default | check
[INFO] maven-install-plugin | install | default-install | install
[INFO] maven-deploy-plugin | deploy | default-deploy | deploy

Lister les phases du plan
#

Une vue par phase au sein du build est disponible. On peut ainsi voir rapidement quels plugins seront exécutés au sein d’une phase.

> mvn buildplan:list-phase

[INFO] --- buildplan-maven-plugin:1.0:list-phase (default-cli) @ buildplan-maven-plugin ---
[INFO] install ------------------------------------------------------------------------------------------
[INFO] + maven-install-plugin | default-install | install
[INFO] generate-sources ---------------------------------------------------------------------------------
[INFO] + maven-plugin-plugin | help-goal | helpmojo
[INFO] process-resources --------------------------------------------------------------------------------
[INFO] + maven-resources-plugin | default-resources | resources
[INFO] test ---------------------------------------------------------------------------------------------
[INFO] + maven-surefire-plugin | default-test | test
[INFO] test-compile -------------------------------------------------------------------------------------
[INFO] + maven-compiler-plugin | default-testCompile | testCompile
[INFO] process-test-resources ---------------------------------------------------------------------------
[INFO] + maven-resources-plugin | default-testResources | testResources
[INFO] verify -------------------------------------------------------------------------------------------
[INFO] + license-maven-plugin | default | check
[INFO] process-classes ----------------------------------------------------------------------------------
[INFO] + maven-plugin-plugin | default-descriptor | descriptor
[INFO] + maven-plugin-plugin | mojo-descriptor | descriptor
[INFO] + animal-sniffer-maven-plugin | check-signature | check
[INFO] compile ------------------------------------------------------------------------------------------
[INFO] + maven-compiler-plugin | default-compile | compile
[INFO] package ------------------------------------------------------------------------------------------
[INFO] + maven-jar-plugin | default-jar | jar
[INFO] + maven-plugin-plugin | default-addPluginArtifactMetadata | addPluginArtifactMetadata
[INFO] + maven-source-plugin | attach-sources | jar-no-fork
[INFO] deploy -------------------------------------------------------------------------------------------
[INFO] + maven-deploy-plugin | default-deploy | deploy

Pour filtrer la description d’une seule phase, utiliser le paramètre buildplan.phase :

mvn buildplan:list-phase -Dbuildplan.phase=test

Lister les plugins
#

On peut grouper les exécutions par plugin.

> mvn buildplan:list-plugin

[INFO] --- buildplan-maven-plugin:1.0:list-plugin (default-cli) @ buildplan-maven-plugin ---
[INFO] maven-deploy-plugin -------------------------------------------------------------------------
[INFO] + deploy | default-deploy | deploy
[INFO] maven-source-plugin -------------------------------------------------------------------------
[INFO] + package | attach-sources | jar-no-fork
[INFO] license-maven-plugin ------------------------------------------------------------------------
[INFO] + verify | default | check
[INFO] maven-resources-plugin ----------------------------------------------------------------------
[INFO] + process-resources | default-resources | resources
[INFO] + process-test-resources | default-testResources | testResources
[INFO] maven-plugin-plugin -------------------------------------------------------------------------
[INFO] + generate-sources | help-goal | helpmojo
[INFO] + process-classes | default-descriptor | descriptor
[INFO] + process-classes | mojo-descriptor | descriptor
[INFO] + package | default-addPluginArtifactMetadata | addPluginArtifactMetadata
[INFO] maven-jar-plugin ----------------------------------------------------------------------------
[INFO] + package | default-jar | jar
[INFO] animal-sniffer-maven-plugin -----------------------------------------------------------------
[INFO] + process-classes | check-signature | check
[INFO] maven-surefire-plugin -----------------------------------------------------------------------
[INFO] + test | default-test | test
[INFO] maven-compiler-plugin -----------------------------------------------------------------------
[INFO] + compile | default-compile | compile
[INFO] + test-compile | default-testCompile | testCompile
[INFO] maven-install-plugin ------------------------------------------------------------------------
[INFO] + install | default-install | install

Le paramètre buildplan.plugin permet de filtrer un plugin en particulier :

mvn buildplan:list-plugin -Dbuildplan.plugin=maven-compiler-plugin

Et voilà comment on peut explorer ce que va exécuter Maven pendant un build !

Publier son site Maven sur GitHub Pages

Sat, 17 Aug 2013 18:10:00 +0200

Tout fier de son projet hébergé sur GitHub, il existe un mécanisme de publication de site statique, les GitHub Pages. Petit tour de piste pour configurer le déploiement de site Maven sur cet espace.

The Maven way
#

Le maven-site-plugin permet de déployer les sites via différents protocoles configurables avec des providers wagon. Coup de chance il existe une section pour l’utilisation des gh-pages: Deploying your Maven site to GitHub’s gh-pages.
Malheureusement je n’ai pas réussi à le faire fonctionner… Je suis tombé sur ce ticket qui donne des pistes (enfin pas sûr que ça fonctionne au final) mais qui indique surtout qu’il faut utiliser Maven SCM Publish Plugin.
Par contre ce n’est pas intégré à la fonctionalité de reporting de Maven, pas de mvn site-deploy out of the box.
Je ne l’ai pas testé, je me suis plutôt rabattu sur le plugin maven développé par GitHub qui avait l’air de répondre à mes attentes.

Plugin GitHub
#

Dans le repository officiel de GitHub est disponible le Site Plugin.
Un petit peu de configuration :

<plugin>
 <artifactId>maven-site-plugin</artifactId>
 <version>3.3</version>
 <configuration>
	 <skipDeploy>true</skipDeploy>
 </configuration>
</plugin>
<plugin>
 <groupId>com.github.github</groupId>
 <artifactId>site-maven-plugin</artifactId>
 <version>0.8</version>
 <configuration>
	 <message>Creating site for ${project.version}</message>
	 <repositoryOwner>_</repositoryOwner>
 <repositoryName>_</repositoryName>
 <server>github</server>
 </configuration>
 <executions>
	 <execution>
 	 <phase>site-deploy</phase>
 <goals>
 	 <goal>site</goal>
 </goals>
 </execution>
 </executions>
</plugin>

avec
repositoryOwner: nom d’utilisateur,
repositoryName: nom du repository,
server: identifiant du serveur dans settings.xml

<servers>
 <server>
 <id>github</id>
 <username>GitHubLogin</username>
 <password>GitHubPassw0rd</password>
 </server>
</servers>

Et voilà mvn site-deploy génère et publie le site sur vos gh-pages (peut prendre une dizaine de minutes avant qu’il ne soit disponible).

Si vous ne l’avez pas encore fait, pensez à utiliser le skin maven-fluido-skin qui modernise le rendu de votre site !

Maven: complétion, couleurs et notifications de bureau

Sun, 14 Apr 2013 14:02:00 +0200

Maven, out of the box n’est pas l’outil le plus sexy du monde… Utilisé dans un IDE, il saura se faire oublié mais il mérite mieux lors de son usage en ligne de commande.

Complétion
#

Il existe des scripts de complétion automatique des commandes Maven.

Les utilisateurs de bash pourront compter sur :

maven-bash-completion, une représentation statique de plugins/goals/options. Celà fonctionne très bien, malheureusement il faut que chaque plugin soit décrit pour pouvoir être reconnu.
Un second script maintenu dans le paquet ubuntu de maven. Il fonctionne sur la même base que le précédent.

Si vous utilisez zsh, deux solutions sont disponibles :

le plugin mvn au sein du framework oh-my-zsh s’occupe de la complétion. En cadeau on a également tout une collection d’alias très pratique.
dans zsh-completions, un script permet de découvrir les goals de manière automatique à la première utilisation d’un plugin (mvn plugin:<TAB>). La première exécution est un peu plus longue mais après la complétion est instantanée (Merci à Thomas Queste qui en a parlé dans les commentaires).

Notifications de bureau
#

Avoir un build rapide c’est bien… seulement il arrive que ce ne soit pas du tout le cas. Rester devant sa console pour un build qui dure plusieurs minutes n’a pas vraiment d’intérêt… Pouvoir être notifié du résultat à la fin de son build devient alors indispensable.

maven-notifier
#

J’ai développé une extension Maven qui permet d’envoyer une notification à la fin d’un build : maven-notifier. Il fonctionne avec tous les systèmes d’exploitation.
Par défaut, l’extension tentera de trouver un notifier disponible sur la machine depuis cette liste d’outils.
Il est possible de configurer le système de notification utilisé et bien d’autres choses (format des messages, etc) en créant un fichier maven-notifier.properties.

Notifier	Capture d’écran
Growl, disponible pour Windows et OS X.	maven-notifier-growl
Snarl, disponible pour Windows	maven-notifier-snarl
terminal-notifier, OS X
notification center OS X (depuis Mavericks)
notify-send pour Linux
SystemTray depuis Java 6
Pushbullet	maven-notifier-pushbullet
Kdialog utilisable avec KDE	maven-notifier-kdialog
notifu disponible pour Windows	maven-notifier-notifu
AnyBar pour OS X et Linux	maven-notifier-anybar
Toaster pour Windows 8
Notify since Java 6
BurntToast for Windows 10
Slack

Les scripts
#

On peut aussi se contenter de wrapper la commande mvn pour récupérer son statut et envoyer une notification.

Growl via growlnotify : Intégration de Growl avec Maven, maven-growl
notification center via terminal-notifier : maven-notification-center
notify-send : Intégration de notify-send avec Maven.

Couleurs
#

La sortie console de Maven est toute terne. Il n’est pas toujours facile d’y retrouver les messages d’erreurs et c’est encore pire pour les messages d’avertissement…

maven-color
#

maven-color ajoute de la couleur dans les logs de Maven.

Les dernières versions de Maven (depuis la version 3.1.x) utilisent SLF4J en interne, cela veut dire que l’on peut choisir l’implémentation de log que l’on veut !
Cet article très complet explique comment avoir une console en couleur avec Log4j 2 ou Logback. C’est la technique utilisée par maven-color

Pour les versions plus anciennes (entre la 3.0.x et la 3.1.0), j’ai utilisé Jansi et remplacé les loggers utilisés en interne par Maven avec un agent. Cela fonctionne avec les goals interactifs, par contre c’est beaucoup moins facile à mettre en place et bien moins résistant aux changements d’implémentation au sein de Maven et du plugin Surefire… maven-color.

Les scripts
#

On peut ajouter un peu de couleur pour y voir plus clair :

Ces scripts sont très biens et faciles à mettre en place, malheureusement ils ne fonctionnent pas avec les goals interactifs. N’espérez pas utiliser maven-release-plugin ou maven-archetype-plugin en mode interactif, les messages de demande de saisis n’apparaitront pas.

Tout en un (pour OS X)
#

Comme c’était dommage de réinstaller toutes ces extensions à la main pour chaque version de Maven, j’ai créé une formule pour brew.

brew tap jcgay/jcgay
brew install maven-deluxe

Celà installera la dernière version de Maven, maven-notifier, maven-color et maven-profiler.

Conclusion
#

Xzibit

Thanks Xzibit for pimping my Maven !

JRebel, le redéploiement c'est à chaud !

Sat, 02 Feb 2013 16:12:00 +0200

Quand on développe des applications web Java EE, on passe généralement son temps à redéployer son application et redémarrer son conteneur… Heureusement on peut compter depuis un moment sur JRebel pour grandement augmenter sa productivité lors des développements en permettant le rechargement à chaud des modifications de façon plus poussé que le Hot Swap intégré à la JVM.

Fonctionnement
#

JRebel est un agent java qui va surveiller les modifications de notre application et les appliquées au sein de la JVM à chaud. Pour celà, l’agent va scanner le classpath à la recherche de fichiers rebel.xml décrivant les ressources à surveiller.

Installation
#

La documentation de JRebel met l’accent sur l’intégration avec les IDE (Eclipse, IntelliJ Idea, Netbeans, MyEclipse) et est très bien faite : JRebel IDE Plugins Personnellement j’utilise rarement les fonctionnalités de déploiement intégrés dans les IDE (peut-être à cause de wtp dans Eclipse…) et préfère utilisé un serveur embedded (dans un plugin Maven par exemple) ou même directement le serveur d’application installé sur mon poste.

On a donc besoin de télécharger une archive de JRebel, disponible ici : Télécharger JRebel

Une fois dezippé, il faut exécuter la configuration de JRebel via bin/jrebel-config.{cmd|sh} et suivre les instructions de l’assistant. Pour ajouter l’agent JRebel à la JVM : -noverify -javaagent:$JREBEL_HOME/jrebel.jar

Configuration de votre application
#

Il faut maintenant s’intéresser à la génération des fichiers de configuration rebel.xml. Il existe un plugin Maven pour faire le travail à notre place : http://zeroturnaround.com/software/jrebel/maven/

<plugin>
 <groupId>org.zeroturnaround</groupId>
 <artifactId>jrebel-maven-plugin</artifactId>
 <version>1.1.3</version>
 <configuration>
 <classpath>
 <resources>
 <resource>
 <includes>
 <include>com/github/jcgay/**</include>
 </includes>
 </resource>
 <resource>
 <directory>src/main/resources</directory>
 </resource>
 </resources>
 </classpath>
 </configuration>
 <executions>
 <execution>
 <id>generate-rebel-xml</id>
 <phase>generate-resources</phase>
 <goals>
 <goal>generate</goal>
 </goals>
 </execution>
 </executions>
</plugin>

Le plugin se base sur le type de votre module pour générer la configuration par défaut (pour par exemple intégrer src/main/webapp aux ressources surveillées). Ce comportement peut-être surchargé si par exemple votre webapp utilise le type maven jar en utilisant war au sein de la configuration du plugin. Le plugin fonctionne très bien au sein des projets multi-module. On peut filtrer avec des include/exclude les ressources à intégrer dans le rechargement de JRebel.

Les chemins générés au sein de la configuration sont absolus par défaut (donc spécifique à votre environnement), il est possible de variabiliser les chemins générés pour les rendre relatifs. Je n’ai jamais utilisé la fonctionalité (je ne package pas la configuration JRebel dans mes artifacts finaux) mais c’est toujours bon à savoir.

Toutes les possibilités de configuration du rebel.xml sont décrites ici : documentation rebel.xml

Vérification du fonctionnement
#

Si l’agent est correctement configuré, on obtient au lancement de la JVM :

[2013-01-25 16:16:04] #############################################################
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] JRebel 5.1.1 (201211271929)
[2013-01-25 16:16:04] (c) Copyright ZeroTurnaround OU, Estonia, Tartu.
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] Over the last 30 days JRebel prevented 
[2013-01-25 16:16:04] at least 95 redeploys/restarts saving you about 3.9 hours.
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] This product is licensed to ******
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] The following plugins are disabled at the moment: 
[2013-01-25 16:16:04] * Click plugin (set -Drebel.click_plugin=true to enable)
[2013-01-25 16:16:04] * JRuby Plugin (set -Drebel.jruby_plugin=true to enable)
[2013-01-25 16:16:04] * Jersey plugin (set -Drebel.jersey_plugin=true to enable)
[2013-01-25 16:16:04] * Oracle ADF Core plugin (set -Drebel.adf_core_plugin=true to enable)
[2013-01-25 16:16:04] * Oracle ADF Faces plugin (set -Drebel.adf_faces_plugin=true to enable)
[2013-01-25 16:16:04] * RESTlet plugin (set -Drebel.restlet_plugin=true to enable)
[2013-01-25 16:16:04] * Seam-Wicket plugin (set -Drebel.seam_wicket_plugin=true to enable)
[2013-01-25 16:16:04] * Spring Data Plugin (set -Drebel.spring_data_plugin=true to enable)
[2013-01-25 16:16:04] * WebObjects plugin (set -Drebel.webobjects_plugin=true to enable)
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] #############################################################

Puis les ressources qui sont surveillées :

[2013-01-25 16:16:06] JRebel: Directory '/home/jcgay/dev/app/target/classes' will be monitored for changes.
[2013-01-25 16:16:06] JRebel: Directory '/home/jcgay/dev/app/src/main/webapp' will be monitored for changes.
[2013-01-25 16:16:06] JRebel: Directory '/home/jcgay/dev/app/src/main/resources will be monitored for changes.

Les classes seront maintenant rechargées dès qu’elles sont compilées depuis l’IDE (pour peu que celui ci soit bien configuré pour compiler les classes au même endroit que Maven).

Les ressources sont rechargées après un hit sur le serveur d’application. Pour chaque ressource rechargée, une entrée est loggée :

[2012-12-20 11:33:56] JRebel: Reloading class 'com.github.jcgay.app.Person'.

Notes
#

La génération de la configuration via le plugin Maven est liée à la phase “generate-resources”. Il est possible que le reste du build écrase cette configuration (par exemple de l’overlay de war, ou du tissage d’aspect à partir du build d’un war dans ses modules). Génaralement dans ce cas je change la phase d’exécution du plugin Maven pour une phase postérieure à celle qui pose problème…
Attention à bien cocher “I use Maven to build my application” dans l’assistant de configuration de JRebel, sinon vous verrez surement le monitoring de plugin JRebel correctement s’activé mais pas celui des ressources de l’application.
Dans IntelliJ Idea, pour que la compilation se fasse bien dans le même répertoire que Maven, il faut cocher “Use Maven output directories”.
Toujours dans Idea, si l’on utilise le debugger, celui si se retrouvera désynchronisé dès la prise en compte d’un rechargement à chaud. Dans ce cas il faut installer le plugin JRebel, et ajouter la propriété -Drebel.debugger_integration=true au lancement de la JVM.

Maven on Jean-Christophe Gay

Utiliser une propriété unique comme version Maven

Définir la version dans une propriété #

Continuous delivery friendly version #

Filtrer les pom à l’installation/déploiement #

Conclusion #

Déployer ses SNAPSHOT avec Travis CI

Configuration de Maven #

Identification #

Stockage dans les paramètres du repository #

Chiffrer ses identifiants #

Configuration de Travis CI #

Mesurer son temps de build Maven

maven-profiler #

maven-timeline #

tesla-profiler #

Le cycle de vie de son build Maven

Configuration #

Afficher le plan du build #

Lister les phases du plan #

Lister les plugins #

Publier son site Maven sur GitHub Pages

The Maven way #

Plugin GitHub #

Maven: complétion, couleurs et notifications de bureau

Complétion #

Notifications de bureau #

maven-notifier #

Les scripts #

Couleurs #

maven-color #

Les scripts #

Tout en un (pour OS X) #

Conclusion #

JRebel, le redéploiement c'est à chaud !

Fonctionnement #

Installation #

Configuration de votre application #

Vérification du fonctionnement #

Notes #

Définir la version dans une propriété
#

Continuous delivery friendly version
#

Filtrer les pom à l’installation/déploiement
#

Conclusion
#

Configuration de Maven
#

Identification
#

Stockage dans les paramètres du repository
#

Chiffrer ses identifiants
#

Configuration de Travis CI
#

maven-profiler
#

maven-timeline
#

tesla-profiler
#

Configuration
#

Afficher le plan du build
#

Lister les phases du plan
#

Lister les plugins
#

The Maven way
#

Plugin GitHub
#

Complétion
#

Notifications de bureau
#

maven-notifier
#

Les scripts
#

Couleurs
#

maven-color
#

Les scripts
#

Tout en un (pour OS X)
#

Conclusion
#

Fonctionnement
#

Installation
#

Configuration de votre application
#

Vérification du fonctionnement
#

Notes
#