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

Notifications de bureau pour Gradle

Wed, 13 May 2015 17:35:00 +0200

Comme (trop ?) souvent avec les builds, le temps parait long… Souvent lancé un peu en tâche de fond, j’aime bien avoir une notification quand ceux ci se terminent.
Gradle propose un plugin par défaut pour enrichir son build de notifications mais on verra comment avoir accès à une panoplie de nouveaux types de notifications !

Gradle Build Announcements
#

C’est le plugin disponible par défaut dans la distribution de Gradle. Il est lui même basé sur le plugin Announce qui permet d’envoyer des notifications personnalisées pendant un build.
Il supporte 4 types de notifications :

twitter
notify-send
Snarl
Growl

Pour l’activer, c’est très simple il suffit de le déclarer dans build.gradle :

apply plugin: 'build-announcements'

ou de le déclarer directement dans $HOME/.gradle/init.gradle pour que le plugin soit actif pour tous les projets :

rootProject {
 apply plugin: 'build-announcements'
}

C’est vraiment très sympa d’avoir cette fonctionnalité disponible directement sans rien installer… Par contre le choix d’applications est assez limité et les notifications ne sont pas très visuelles (l’icône est toujours la même quelque soit l’état du build par exemple).

Gradle notifier
#

Comme j’avais déjà mes notifications pour Maven avec maven-notifier, j’en ai profité pour les porter vers Gradle avec gradle-notifier !

Il supporte l’envoi de notifications vers :

Notifier	Screenshot
Growl, pour Windows et OS X.
Snarl, pour Windows
terminal-notifier, OS X
notification center OS X (depuis Mavericks)
notify-send pour Linux
SystemTray depuis Java 6
Pushbullet
Kdialog pour KDE
notifu for Windows
AnyBar pour OS X et Linux
Toaster pour Windows 8
Notify since Java 6
BurntToast for Windows 10
Slack

Installation
#

Le plugin peut être ajouté dans la phase d’initialisation ou directement au sein d’un projet.

Script d’initialisation
#

Pa exemple, créer (ou modifier) le fichier $HOME/.gradle/init.gradle :

initscript {
 repositories {
 mavenCentral()
 }

 dependencies {
 classpath group: 'fr.jcgay', name: 'gradle-notifier', version: '1.1.0'
 }
}

rootProject {
 apply plugin: fr.jcgay.gradle.notifier.GradleNotifierPlugin
}

Script du projet
#

Dans le script build.gradle, ajouter :

buildscript {
 repositories {
 mavenCentral()
 }
 
 dependencies {
 classpath group: 'fr.jcgay', name: 'gradle-notifier', version: '1.1.0'
 }
}

apply plugin: 'fr.jcgay.gradle-notifier'

ou en utilisant le mécanisme de plugin introduit depuis Gradle 2.1:

plugins {
 id "fr.jcgay.gradle-notifier" version "1.1.0"
}

Configuration
#

Reposant sur send-notification, la configuration des applications et le choix de celle utilisée pour recevoir les notifications peut se faire dans le fichier $HOME/.send-notification (Voir les paramètres disponibles dans la documentation).

Ou bien l’outil est configurable directement au sein d’un script Gradle :

notifier {
 implementation = 'notificationcenter'
 threshold {
 time = 10
 unit = java.util.concurrent.TimeUnit.SECONDS
 }
 growl {
 port = 23053
 host = 'localhost'
 password = 'azerty123'
 }

Et voilà plus moyen d’oublier son build au fin fond d’une console !

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 !

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 !

Build 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 #

Notifications de bureau pour Gradle

Gradle Build Announcements #

Gradle notifier #

Installation #

Script d’initialisation #

Script du projet #

Configuration #

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 #

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 #

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
#

Gradle Build Announcements
#

Gradle notifier
#

Installation
#

Script d’initialisation
#

Script du projet
#

Configuration
#

maven-profiler
#

maven-timeline
#

tesla-profiler
#

Configuration
#

Afficher le plan du build
#

Lister les phases du plan
#

Lister les plugins
#

Complétion
#

Notifications de bureau
#

maven-notifier
#

Les scripts
#

Couleurs
#

maven-color
#

Les scripts
#

Tout en un (pour OS X)
#

Conclusion
#