Maven est un framework de scripting de haut-niveau pour Java qui utilise des notions telles qu'une structure normalisée d'arborescence et des cycles de vie normalisés, "Convention over Configuration", et une gestion déclarative des dépendances pour simplifier le scripting de bas-niveau que l'on trouve souvent dans un script de build Ant typique. Avec Maven, votre projet utilise un cycle de vie normalisé et bien défini — compile, test, package, deploy, etc. Chaque phase de cycle est associée avec un plugin Maven. Les différents plugins Maven utilisent la structure d'arborescence normalisée pour traiter ces tâches avec un minimum d'intervention de votre part. Vous pouvez aussi étendre Maven en redéfinissant les configurations de plugin par défaut ou en invoquant des plugins supplémentaires.

Jenkins fournit un excellent support pour Maven, et comprend parfaitement les structures de projet et les dépendances Maven. Vous pouvez soit demander à Jenkins d'installer automatiquement une version de Maven (comme nous le faisons avec Maven 3 dans l'exemple), ou fournir un chemin vers une installation locale de Maven (voir Figure 4.7, “Configurer Maven dans Jenkins”). Vous pouvez configurer autant de versions de Maven pour vos projets de build que vous le voulez, et utiliser différentes versions de Maven pour différents projets.

Si vous cochez la case à cocher Installer automatiquement, Jenkins téléchargera et installera la versions demandée de Maven pour vous. Vous pouvez soit demander à Jenkins de télécharger Maven directement depuis le site Apache, soit depuis une URL (a priori locale) de votre choix. C'est un excellent choix si vous utilisez des builds distribués, et puisque Maven est multi-plateformes, cela fonctionnera sur n'importe quelle machine. Vous n'avez pas besoin d'installer explicitement Maven sur chaque machine de build — la première fois qu'une machine de build aura besoin d'utiliser Maven, elle en téléchargera une copie et l'installera dans le répertoire tools du répertoire racine de Jenkins.

Il est parfois nécessaire de passer des options système à votre processus de construction Maven. Par exemple, il est souvent utile de donner à Maven un peu plus de mémoire pour des tâches lourdes comme la couverture de code ou la génération de site. Maven vous permet de faire cela en positionnant la variable MAVEN_OPTS. Dans Jenkins, vous pouvez définir une valeur par défaut pour tout le système, afin de l'utiliser dans tous les projets (voir Figure 4.8, “Configurer la variable système MVN_OPTS”). C'est pratique si vous voulez utiliser des options standards de mémoire (par exemple) pour tous vos projets, sans avoir à le configurer dans chaque projet à la main.

Ant est un langage de script de build pour Java largement utilisé et très connu. C'est un langage de scripting flexible, extensible, relativement bas-niveau utilisé dans un grand nombre de projets opensource. Un script de build Ant (typiquement nommé build.xml) est constitué d'un certain nombre de targets. Chaque target effectue une tâche particulière dans le processus de build, comme compiler votre code ou exécuter vos tests unitaires. Il fonctionne en exécutant des tasks, qui portent une partie spécifique de la tâche de build, comme invoquer javac pour compiler votre code, ou créer un nouveau répertoire. Les targets ont aussi des dependencies, indiquant l'ordre dans lequel vos tâches de build doivent être exécutées. Par exemple, vous devez compiler votre code avant de lancer vos tests unitaires.

Jenkins fournit en standard un support excellent pour Ant — vous pouvez invoquer les tâches Ant depuis votre tâche de build, en fournissant les propriétés permettant de personnaliser le processus comme cela est nécessaire. Nous regardons comment faire cela en détail plus loin dans le livre.

Si Ant est disponible dans le path système, Jenkins le trouvera. Toutefois, si vous voulez savoir précisément quelle version de Ant vous êtes en train d'utiliser, ou si vous avez besoin de pouvoir utiliser différentes versions de Ant sur différentes tâches de build, vous pouvez configurer autant d'installations de Ant que vous le souhaitez (voir Figure 4.9, “Configurer Ant dans Jenkins”). Fournissez simplement un nom et un répertoire d'installation pour chaque version de Ant dans la section Ant de l'écran Configurer le système. Vous pourrez ensuite choisir quelle version de Ant vous voulez utiliser pour chaque projet.

Si vous cochez la case à cocher Installer automatiquent, Jenkins téléchargera et installera Ant dans le répertoire tools du répertoire racine de Jenkins, exactement comme il le fait pour Maven. Il téléchargera une installation de Ant la première fois qu'une tâche de build aura besoin d'utiliser Ant, soit depuis le site web Apache, soit depuis une URL locale. Encore une fois, ceci est un moyen formidable de normaliser vos serveurs de build et de faciliter l'ajout de nouveaux serveurs de builds distribués à une infrastructure existante.

Si vous exécutez votre serveur de build sous Unix ou Linux, Jenkins vous permettra d'insérer des scripts shells dans vos tâches de build. C'est pratique pour effectuer des tâches bas-niveau, liées à l'OS que vous ne voulez pas faire avec Ant ou Maven. Dans la section Shell, vous définissez le Shell par défaut qui sera utilisé pour exécuter ces scripts Shell. Par défaut, c'est /bin/sh, mais parfois vous pouvez vouloir modifier cela pour utiliser un autre interpréteur de commande comme bash ou Perl.

Sous Windows, la section Shell ne s'applique pas — vous utilisez le scripting batch Windows à la place. Donc, sur un serveur de build Windows, vous devriez laisser ce champ vierge.