Ce site met a disposition le build journalier de la traduction francaise du Maven: The Definitive Guide
Consultez :
  • Les documents de reference sur le projet original
  • Les sources de la traduction fr sur GitHub
  • maven


    Chapitre 8. Optimiser et remanier les POMs

    8.1. Introduction

    Dans le Chapitre 7, Un projet multimodule d'entreprise, nous avons vu combien d'éléments de Maven doivent intervenir de concert pour produire un build multimodule complètement fonctionnel. Bien que l'exemple du chapitre précédent représente une véritable application — une application qui interagit avec une base de données, un web service, et qui elle-même présente deux interfaces : une au travers d'une application web, et l'autre via la ligne de commande — cet exemple de projet reste convenu. Présenter la complexité d'un véritable projet demanderait un livre bien plus épais que celui que vous avez entre les mains. Dans la réalité les applications évoluent année après année et sont souvent maintenues par des équipes de développeurs nombreuses et variées, chacune se concentrant sur sa propre partie. Dans un véritable projet, vous devez souvent évaluer les décisions et la conception faites par d'autres. Dans ce chapitre, nous allons prendre du recul par rapport aux exemples que vous avez vus dans la Partie I, « Maven par l'exemple », et nous allons nous demander quelles sont les optimisations à réaliser avec ce que nous avons appris sur Maven. Maven est un outil très adaptable qui peut devenir simple ou complexe selon votre besoin. C'est pour cette raison qu'il existe des centaines de manières différentes de configurer votre projet Maven pour réaliser une même tâche mais aucune qui ne saurait prétendre être la “bonne”.

    N'allez par voir dans cette dernière phrase une autorisation à détourner à Maven pour lui faire réaliser des choses pour lesquelles il n'a pas été conçu. Même si Maven permet des approches diverses et variées, il existe sûrement une approche "à la Maven" qui utilise Maven comme il a été conçu pour être utilisé et vous rend ainsi plus efficace. Dans ce chapitre, nous allons vous montrer certaines optimisations que vous pouvez appliquer à un projet Maven existant. Pourquoi n'avons nous pas commencé avec un POM optimisé en premier lieu ? Concevoir des POMs avec une valeur pédagogique est bien différent de la conception de POMs efficaces. S'il est sûrement plus facile de définir certaines valeurs dans votre ~/.m2/settings.xml que de déclarer un profil dans un pom.xml, l'écriture d'un livre, comme sa lecture, dépend de la fréquence à laquelle on va introduire de nouveaux concepts ainsi que du moment où ils seront introduits, ni trop tôt ni trop tard. Dans la Partie I, « Maven par l'exemple », nous avons fait attention à ne pas vous noyer sous trop d'informations. Et ce faisant, nous avons dû éviter certains concepts de base comme la balise dependencyManagement dont nous parlerons dans ce chapitre.

    À plusieurs moments dans la Partie I, « Maven par l'exemple » les auteurs de ce livre ont choisi des raccourcis ou ont évité un point de détail important pour rester concentrés sur l'essentiel du chapitre. Vous avez appris à créer un projet Maven, vous l'avez compilé et installé sans avoir à parcourir des centaines de pages qui vous décrivaient toutes les options et possibilités. Nous avons procédé ainsi car nous pensons qu'il est important pour un nouvel utilisateur de Maven d'obtenir rapidement des résultats plutôt que de suivre une très longue, voire interminable histoire. Une fois que vous avez commencé à utiliser Maven, vous devriez savoir comment analyser vos propres projets et POMs. Dans ce chapitre, nous prenons du recul pour étudier ce qu'il nous reste après l'exemple du Chapitre 7, Un projet multimodule d'entreprise.