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


    14.5.4. Section dependencySets

    Une des fonctionnalités les plus demandées pour les assemblies est l'ajout des dépendances d'un projet dans l'archive assembly. Les balises files et fileSets traitent les fichiers de votre projet, cependant une dépendance n'est pas un fichier qui se trouve dans les répertoires de votre projet. Les artefacts dont dépend votre projet sont résolus par Maven lors du build. Les artefacts de dépendance sont une notion abstraite, il n'ont pas un chemin bien défini et sont résolus en utilisant un ensemble symbolique de coordonnées Maven. Puisque file et fileSet exigent un chemin réel, les dépendances seront incluses ou excluses d'un assembly par une combinaison de coordonnées Maven et de scope.

    La forme la plus simple de la balise dependencySet est une balise vide :

    <assembly>
      ...
      <dependencySets>
        <dependencySet/>
      </dependencySets>
      ...
    </assembly>

    La balise dependencySet ci-dessus va rechercher toutes les dépendances d'exécution de votre projet (le scope runtime scope inclut le contenu du scope compile implicitement), et va ensuite les ajouter au répertoire racine de l'archive assembly. Elle va aussi copier l'artefact principal de votre projet, s'il existe, dans ce répertoire racine.

    Note

    Une minute ? Je pensais que la balise dependencySet gérait l'inclusion des dépendances de mon projet, pas son archive principale ? Cet effet secondaire non-intuitif était un bug très utilisé de la version 2.1 du plugin Assembly, et, comme Maven accorde une très grande importance à la compatibilité ascendante, ce comportement non-intuitif et incorrect a dû être préservé pour la version 2.2. Vous pouvez interdire ce comportement en mettant à false la balise useProjectArtifact.

    Même si l'ensemble des dépendances par défaut peut être très utile sans configuration supplémentaire, cette section du descripteur d'assembly supporte de nombreuses options de configuration pour vous permettre d'adapter son comportement à vos besoins spécifiques. Par exemple, la première chose que vous pourriez vouloir faire par rapport à cette liste de dépendances est d'exclure l'artefact du projet en mettant useProjectArtifact à false (sa valeur par défaut est à true pour des raisons historiques). Cela vous permettra de gérer le résultat du build de votre projet indépendamment des fichiers des dépendances. De même, vous pouvez choisir de décompresser les dépendances en mettant la balise unpack à true (elle est à false par défaut). Lorsque l'option unpack est activée, le plugin Assembly va décompresser les contenus des dépendances dans le répertoire racine de l'archive.

    À partir maintenant, vous pouvez faire plusieurs choses avec cet ensemble de dépendances. Les sections qui vont suivre présentent comment définir l'endroit où seront enregistrées ces dépendances et comment inclure et exclure des dépendances selon leur scope. Enfin, nous nous étendrons sur cette fonctionnalité de décompression des dépendances en explorant certaines de ses options avancées.

    14.5.4.1. Configurer l'emplacement des dépendances

    C'est la combinaison de deux options de configuration qui détermine où va se retrouver un fichier de dépendance dans l'archive assembly : outputDirectory et outputFileNameMapping. Vous pouvez configurer l'emplacement des dépendances dans votre assembly selon les propriétés des artefacts des dépendances. Disons que vous voulez mettre toutes vos dépendances dans des répertoires qui correspondent au groupId de l'artefact. Dans ce cas, vous pouvez utiliser la balise outputDirectory sous dependencySet et lui donner pour valeur :

    <assembly>
      ...
      <dependencySets>
        <dependencySet>
          <outputDirectory>${artifact.groupId}</outputDirectory>
        </dependencySet>
      </dependencySets>
      ...
    </assembly>

    Cela aura pour effet de mettre chaque dépendance dans un répertoire dont le nom correspond au groupId de son artefact.

    Si vous voulez aller plus loin dans la personnalisation et que vous souhaitez retirer le numéro de version du nom de fichier des dépendances. Il suffit de configurer le renommage des dépendances grâce à la balise outputFileNameMapping comme suit :

    <assembly>
      ...
      <dependencySets>
        <dependencySet>
          <outputDirectory>${artifact.groupId}</outputDirectory>
          <outputFileNameMapping>
            ${artifact.artifactId}.${artifact.extension} 
          </outputFileNameMapping>
        </dependencySet>
      </dependencySets>
      ...
    </assembly>

    Dans l'exemple précédent, une dépendance sur commons:commons-codec version 1.3, se retrouverait dans le fichier commons/commons-codec.jar.

    14.5.4.2. Interpolation de propriétés pour l'emplacement des dépendances

    Comme nous l'avons déjà mentionné dans la Section 14.4.1, « Référence de propriété dans un descripteur d'assembly », aucun de ces éléments n'est interpolé avec le reste du descripteur d'assembly. En effet, leurs valeurs brutes doivent être traitées par des interpréteurs d'expression d'artefact spécifiques.

    Les expressions utilisables pour ces deux éléments sont légèrement différentes. Les expressions ${project.*}, ${pom.*} et ${*} qui sont disponibles dans le POM et dans le reste du descripteur le sont aussi dans ces deux cas. Pour la balise outputFileNameMapping le traitement suivant est appliqué pour résoudre les expressions :

    1. Si l'expression correspond au pattern ${artifact.*} :

      1. Recherche dans l'instance Artifact de la dépendance (résolution des attributs : groupId, artifactId, version, baseVersion, scope, classifier et file.*)

      2. Recherche dans l'instance ArtifactHandler de la dépendance (résolution de : expression)

      3. Recherche dans l'instance du projet associé à l'artefact de la dépendance (résolution : principalement les propriétés du POM)

    2. Si l'expression correspond au pattern ${pom.*} ou ${project.*}:

      1. Recherche dans l'instance du projet (MavenProject) du build en cours.

    3. Si l'expression correspond au pattern ${dashClassifier?} et que l'instance Artifact de la dépendance a un classifier, résoud jusqu'au classifieur précédé d'un tiret (-classifier). Sinon résoud comme étant une chaîne vide.

    4. Essaye de résoudre l'expression avec l'instance du projet du build en cours.

    5. Essaye de résoudre l'expression avec les propriétés du POM du build en cours.

    6. Essaye de résoudre l'expression avec les propriétés système disponibles.

    7. Essaye de résoudre l'expression avec les variables d'environnement du système d'exploitation.

    La valeur de la balise outputDirectory est interpolée de manière assez semblable, à la différence près qu'il n'y a pas d'information du type ${artifact.*} disponible. Seules les instances ${project.*} des artefacts permettent de résoudre les expressions. Donc les expressions associées à ces patterns ne sont pas disponibles (il s'agit des éléments 1a, 1b, et 3 de la liste ci-dessus).

    Comment sait-on quand utiliser outputDirectory et outputFileNameMapping ? Quand les dépendances sont décompressées, seul l'outputDirectory est utilisé pour calculer l'emplacement final. Quand les dépendances sont gérées comme un tout (c'est à dire non décompressées), les deux éléments outputDirectory et outputFileNameMapping peuvent être utilisés ensemble. Quand ils le sont, le résultat est équivalent à :

    <archive-root-dir>/<outputDirectory>/<outputFileNameMapping>

    Quand l'outputDirectory est absent, il n'est pas utilisé. Quand c'est l'outputFileNameMapping qui est absent, on prend sa valeur par défaut qui est : ${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}

    14.5.4.3. Inclusion et exclusion de dépendance par scope

    Dans la Section 9.4, « Dépendances d'un projet », nous avons noté que toutes les dépendances d'un projet ont un scope. Le scope détermine le moment où une dépendance sera utilisée au cours du processus de build. Par exemple, les dépendances dans le scope test ne font pas partie du classpath au moment de la compilation du code source du projet ; par contre, elles font partie du classpath de compilation des tests unitaires. C'est fait ainsi car le code source de votre projet ne devrait pas contenir du code spécifique pour les tests. En effet, tester n'est pas une des fonctions de votre projet (c'est une fonction du processus de build du projet). De même, les dépendances dans le scope provided doivent être présentes dans l'environnement où sera déployé le projet. Cependant, si un projet dépend d'une dépendance provided particulière, il est possible qu'il ait besoin de celle-ci pour compiler. C'est pour cette raison que les dépendances du scope provided sont présentes dans le classpath de compilation mais qu'elles ne sont pas empaquetées avec l'artefact ou un assembly du projet.

    Dans cette même Section 9.4, « Dépendances d'un projet », nous avions vu que les scopes de dépendances en induisent d'autres. Par exemple, le scope de dépendance runtime inclut les dépendances du scope compile, car toutes les dépendances utilisées au moment de la compilation (sauf celles du scope provided) seront nécessaires pour l'exécution du code. Les manières dont un scope d'une dépendance directe affecte le scope des dépendances transitives sont très complexes. Dans un descripteur d'assembly Maven, nous pouvons utiliser les scopes pour filtrer des ensembles de dépendances et leur appliquer des traitements différents .

    Par exemple, si nous projetons de packager une application web avec Jetty et créer ainsi une application autonome, nous allons devoir inclure toutes les dépendances du scope provided dans les répertoires du Jetty que nous intégrons. Cela nous assurera que ces dépendances provided sont effectivement présentes dans l'environnement d'exécution. Les dépendances d'exécution qui ne font pas partie du scope provided continuent à aller dans le répertoire WEB-INF/lib, donc ces deux ensembles de dépendances doivent être traités distinctement. Ces blocs de dépendances ressemblent au document XML qui suit.

    Exemple 14.9. Définition de blocs de dépendances par l'utilisation des scopes

    <assembly>
      ...
      <dependencySets>
        <dependencySet>
          <scope>provided</scope>
          <outputDirectory>lib/${project.artifactId}</outputDirectory>
        </dependencySet>
        <dependencySet>
          <scope>runtime</scope>
          <outputDirectory>
            webapps/${webContextName}/WEB-INF/lib
          </outputDirectory>
        </dependencySet>
      </dependencySets>
      ...
    </assembly>

    Les dépendances du scope provided sont ajoutées au répertoire lib/ situé à la racine de l'assembly. Ce répertoire va contenir l'ensemble des bibliothèques qui seront incluses dans le classpath global d'exécution de Jetty. Nous utilisons un sous-répertoire dont le nom est l'artifactId du projet pour retrouver plus facilement d'où vient une bibliothèque particulière. Les dépendances d'exécution sont incluses dans le répertoire WEB-INF/lib de l'application web, qui se trouve dans le sous-répertoire standard de Jetty : webapps/, et dont le nom est donné par la configuration de la propriété webContextName du POM. Ce que nous venons de faire dans cet exemple est de séparer les dépendances spécifiques à l'application de celles qui sont présentes dans le classpath global d'un conteneur de servlets.

    Cependant, séparer en ne tenant compte que du scope peut s'avérer insuffisant, notamment dans le cas d'applications web. Il est tout à fait concevable qu'une ou plusieurs des dépendances pour l'exécution soient un assemblage de ressources standardisées et non-compilées qui seront utilisées par l'application web. Par exemple, nous pourrions avoir un ensemble d'applications qui réutiliseraient le même ensemble de fichiers de Javascript, CSS, SWF et d'images. Pour faciliter la standardisation de ces ressources, une bonne pratique consiste à les mettre dans une archive et de les déployer sur un dépôt Maven. À partir de ce moment là, elles peuvent être référencées comme une dépendance Maven standard - éventuellement comme une dépendance de type zip - normalement dans le scope runtime. Souvenez-vous qu'il s'agit de ressources et non d'une dépendance du code de l'application vers un binaire ; et donc il ne faut pas les inclure dans le répertoire WEB-INF/lib. Ces archives de ressources doivent être séparées des dépendances binaires d'exécution et décompressées à la racine de l'application web. Pour pouvoir effectuer ce type de séparation, nous allons utiliser les patterns d'inclusion et d'exclusion qui se basent sur les coordonnées d'une dépendance.

    En d'autres termes, nous allons supposer que vous avez trois ou quatre applications web qui réutilisent les mêmes ressources et que vous voulez créer un assembly qui met les dépendances du scope provided dans le répertoire lib/, les dépendances du scope runtime dans webapps/<contextName>/WEB-INF/lib et enfin décompresse une dépendance particulière du scope runtime à la racine de votre application web. Nous pouvons réaliser tout ça car le plugin Assembly permet de définir plusieurs patterns d'inclusion et d'exclusion pour un même élément dependencySet. Dans la prochaine section, nous allons essayer de développer cette idée.

    14.5.4.4. Configuration fine : inclusion et exclusion de dépendances

    Une dépendance de ressources peut être une simple liste de ressources (CSS, Javascript, images ...) dans un projet dont un assembly crée une archive de type ZIP. En fonction des particularités de votre application web, vous voudrez distinguer les dépendances de ressources des dépendances de binaires grâce à leur type. La plupart des applications web vont dépendre d'autres dépendances de type jar. Du coup, il est possible de dire avec certitude que toutes les dépendances de type zip sont des dépendances de ressources. Or, nous pourrions avoir une situation où les ressources sont conservées sous un format jar mais que nous pouvons distinguer les ressources par un classifieur resources. Dans tous les cas, nous pouvons spécifier un pattern d'inclusion pour cibler ces dépendances de ressources et appliquer une logique différente que celle utilisée pour les binaires. Nous pouvons effectue cette distinction par l'intermédiaire de balises includes et excludes dans le dependencySet.

    Les balises includes et excludes sont des listes. Elles acceptent des sous-éléments du type include et exclude. Chaque balise include et exclude contient une valeur sous forme de chaîne de caractère et pouvent contenir des caractères jokers. Les dépendances peuvent respecter ces patterns de plusieurs façons. Généralement, trois formats de pattern sont supportés :

    groupId:artifactId - sans la version

    Utilisez ce pattern pour trouver des dépendances par groupId et artifactId

    groupId:artifactId:type[:classifier] - id de conflit

    Ce pattern vous permet de fournir un ensemble plus large de coordonnées pour créer des patterns include/exclude plus spécifiques.

    groupId:artifactId:type[:classifier]:version - identité complète de l'artefact

    Si vous avez à récupérer un artefact bien spécifique, vous pouvez renseigner l'intégralité des coordonnées.

    Tous ces formats de patterns supportent l'utilisation du joker ‘*’, il permet de remplacer n'importe quelle sous-section de l'identité et peut être employé dans plusieurs sous-sections (bloc entre ':'). En outre, notez que la section classifieur du pattern ci-dessus est facultative, les dépendances qui n'ont pas de classifieur ne prennent pas en compte la section 'classificateur' de ce pattern.

    Dans l'exemple donné ci-dessus, la distinction essentielle est le type zip de l'artefact et il faut noter qu'aucune des dépendances n'a de classifieur, le pattern suivant serait respecté par toutes les ressources de type :

    *:zip

    Le pattern ci-dessus utilise la seconde identité de la dépendance : l'id de conflit. Maintenant que nous avons un pattern qui distingue les dépendances de ressources des dépendances de binaires, nous pouvons modifier notre liste de dépendances pour gérer ces archives différemment :

    Exemple 14.10. Utilisation des l'inclusion et d'exclusion de dépendances dans le dependencySets

    <assembly>
      ...
      <dependencySets>
        <dependencySet>
          <scope>provided</scope>
          <outputDirectory>lib/${project.artifactId}</outputDirectory>
        </dependencySet>
        <dependencySet>
          <scope>runtime</scope>
          <outputDirectory>
            webapps/${webContextName}/WEB-INF/lib
          </outputDirectory>
          <excludes>
            <exclude>*:zip</exclude>
          </excludes>
        </dependencySet>
        <dependencySet>
          <scope>runtime</scope>
          <outputDirectory>
            webapps/${webContextName}/resources
          </outputDirectory>
          <includes>
            <include>*:zip</include>
          </includes>
          <unpack>true</unpack>
        </dependencySet>
      </dependencySets>
      ...
    </assembly>

    Dans l'Exemple 14.10, « Utilisation des l'inclusion et d'exclusion de dépendances dans le dependencySets », la liste de dépendances du scope runtime de notre dernier exemple a été mise à jour pour exclure les dépendances de type ressource. Seules les dépendances binaires (c'est à dire celles qui ne sont pas de type zip) sont ajoutées dans le répertoire WEB-INF/lib de l'application. Les dépendances de ressources sont regroupées dans un seul ensemble de dépendances. Cet ensemble est configuré pour copier ses dépendances dans le répertoire ressource de l'application. La balise includes du dernier dependencySet annule les exclusions du dependencySet précédent. Ainsi, les dépendances ressources sont incluses en utilisant un seul pattern d'identité : *:zip. La dernière balise dependencySet fait référence à des ressources partagées, elle est configurée pour décompresser celles-ci à la racine de l'application web.

    L'Exemple 14.10, « Utilisation des l'inclusion et d'exclusion de dépendances dans le dependencySets » présume que le projet contenant les ressources partagées dispose d'un type différent des autres dépendances. Que se passerait-il si celles-ci avaient le même type que celui des autres dépendances ? Comment différencieriez-vous cette dépendance ? Dans ce cas, si une dépendance de ressources partagées a été packagée comme un JAR avec le classificateur de type resources, vous pouvez changer le pattern d'identité pour qu'il filtre cette dépendance :

    *:jar:resources

    Au lieu d'accepter les artefacts de type zip sans classifieur, nous retenons ici les artefacts de type jar avec un classifieur resources.

    Comme pour la section fileSets, dependencySets supporte l'utilisation du flag useStrictFiltering. Lorsque celui-ci est activé, n'importe quel pattern qui n'accepte aucune dépendance fera échouer l'assembly, et donc par conséquent, le build. Cela est très pratique comme soupape de sécurité, pour vous assurer que les dépendances de votre projet et votre descripteur d'assembly sont bien synchronisés. Par défaut, ce flag est désactivé pour des raisons de rétrocompatibilité.

    14.5.4.5. Dépendances transitives, pièces jointes et artefacts de projet

    La section dependencySet vous propose deux autres mécanismes pour vous aider dans le choix de vos artefacts : la sélection de dépendances transitives et la possibilité de travailler avec des artefacts du projet. Ces deux fonctionnalités proviennent de la nécessité de supporter des configurations existantes qui utilisent une définition un peu plus libérale du mot "dépendance". Comme premier exemple, examinons l'artefact principal du projet. Dans la majorité des cas, il ne doit pas être considéré comme une dépendance. Pourtant, les plus anciennes versions du plugin Assembly l'utilisaient dans le calcul des dépendances. Pour fournir une rétrocompatibilité avec cette "fonctionnalité", la version 2.2 du plugin Assembly dispose d'un flag à mettre dans le dependencySet, celui-ci est appelé useProjectArtifact. La valeur par défaut de ce flag est true. Par défaut, un ensemble de dépendances prendra en compte l'artefact du projet dans la sélection de ses dépendances. Si vous préférez gérer l'artefact du projet séparément, affectez ce flag à false.

    Astuce

    Les auteurs de ce livre vous recommandent de toujours laisser le flag useProjectArtifact à false.

    Comme extension naturelle à l'inclusion d'un artefact projet, les artefacts rattachés à un projet peuvent également être gérés par un dependencySet en utilisant le flag useProjectAttachments (celui-ci est désactivé par défaut). Activer ce flag permet aux patterns qui précisent des classifieurs et des types d'artefacts de prendre en compte les artefacts rattachés. Ils partagent la même identité groupId/artifactId/version, mais diffèrents type et classifier. Cette fonctionnalité peut s'avérer utile pour inclure les JARs de Javadoc ou de source dans un assembly.

    En plus de traiter avec des artefacts du projet, il est également possible de prendre en compte les dépendances transitives pour calculer un ensemble de dépendances grâce à deux paramètres. Le premier, appelé useTransitiveDependencies (et activé par défaut), permet d'activer l'inclusion des dépendances transitives lors de la sélection par pattern. Comme exemple pour savoir comment il peut être utilisé, considérez ce qui arrive lorsque votre POM a une dépendance sur un autre assembly. Cet assembly aura (probablement) un classifieur qui permet de le distinguer de l'artefact principal du projet, ce qui en fait une pièce jointe. Cependant, une particularité du processus de résolution des dépendances Maven est que les informations des dépendances transitives pour l'artefact principal sont toujours utilisées pour résoudre l'artefact de l'assembly. Si l'assembly package les dépendances en lui, dans ce cas, utiliser la résolution des dépendances transitives dupliquerait ces dépendances. Pour éviter cela, nous pouvons simplement utiliser le flag useTransitiveDependencies en le positionnant à false.

    L'autre flag permettant de résoudre les dépendances est plus subtil. Il est appelé useTransitiveFiltering et sa valeur par défaut est false. Pour comprendre ce que fait ce flag, nous devons d'abord comprendre quelles informations sont disponibles pour un artefact donné lors du processus de résolution des dépendances. Quand un artefact est une dépendance d'un autre (c'est à dire avec au moins un niveau intermédiaire entre lui et votre POM), il possède ce que Maven appelle un "chemin de dépendances". Il s'agit d'une liste de chaînes de caractères qui correspondent à l'identité complète de chaque artefact (groupId:artifactId:type:[classifier:]version) de dépendances entre cet artefact et votre POM. Si vous vous rappelez des trois types d'identités des artefacts disponibles pour écrire un pattern, vous remarquerez que les entrées dans ce chemin de dépendances - l'identité complète de l'artefact - correspondent au troisième type. Lorsque le flag useTransitiveFiltering est positionné à true, toutes les entrées du chemin de dépendances d'un artefact peuvent agir sur l'inclusion ou l'exclusion de cet artefact.

    Si vous envisagez l'utisation de ce filtrage transitif, prennez garde ! Un artefact peut être inclus à partir de nombreux emplacement dans un graphe de dépendance, mais dans Maven 2.0.9, seul le premier chemin de dépendances est utilisé pour ce type de sélection. Cela peut conduire à des problèmes difficiles à résoudre dans la collecte des dépendances de votre projet.

    Avertissement

    La plupart des assemblies ne nécessitent pas ce niveau de contrôle sur les listes de dépendances. Réflêchissez attentivement pour savoir si vous en avez vraiment besoin. Astuce : ce n'est probablement pas le cas.

    14.5.4.6. Options avancées de dépaquetage

    Comme nous l'avons vu précédemment, certaines dépendances de projet ont besoin d'être décompressées durant la création d'un assembly. Dans les exemples ci-dessus, la décision de savoir s'il fallait décompresser ou pas était simple. Elle ne tient pas compte de ce qui doit être dépaqueté, ou plus important, de ce qui ne doit pas l'être. Pour obtenir plus de contrôle sur le processus de dépaquetage, vous pouvez configurer la balise unpackOptions dans votre dependencySet. Ainsi, vous avez la possibilité de choisir quels fichiers vous voulez inclure dans votre assembly, et quels fichiers doivent être filtrés pour résoudre des expressions à partir des informations du POM. En fait, les options disponibles pour dépaqueter vos ensembles de dépendances sont similaires à celles disponibles pour l'inclusion ou l'exclusion de fichier.

    Pour continuer notre exemple d'application web, supposons que certaines dépendances de ressources aient été zippées avec un fichier qui décrit les détails de leur licence de distribution. Dans le cas de notre application web, ces licences se présenteront sous la forme d'un fichier NOTICES inclu dans notre paquetage. Pour exclure ce fichier, ajoutons-le simplement aux options de dépaquetage dans la balise dependencySet qui gère les artefacts de ressources :

    Exemple 14.11. Exclusion de fichiers dans le dépaquetage d'une dépendance

    <asembly>
      ...
      <dependencySets>
        <dependencySet>
          <scope>runtime</scope>
          <outputDirectory>
            webapps/${webContextName}/resources
          </outputDirectory>
          <includes>
            <include>*:zip</include>
          </includes>
          <unpack>true</unpack>
          <unpackOptions>
            <excludes>
              <exclude>**/LICENSE*</exclude>
            </excludes>
          </unpackOptions>
        </dependencySet>
      </dependencySets>
      ...
    </assembly>

    Notez que la balise exclude que nous utilisons ressemble beaucoup à celle de la déclaration du fileSet. Ici, nous excluons les fichiers qui commencent par le mot LICENSE des répertoires de nos artefacts de ressources. Vous pouvez considèrer la section des options de dépaquetage comme une seconde balise fileSet appliquée à chaque dépendance faisant partie de cet ensemble. En d'autres mots, il s'agit d'un fileSet utilisé pour le dépaquetage des dépendances. Tout comme nous avons spécifié un modèle d'exclusion pour les dossiers dans les dépendances de ressources afin de bloquer certains fichiers, vous pouvez également choisir un ensemble restreint de fichiers à inclure en utilisant la section includes. La même configuration que celle définissant inclusions et exclusions dans les fileSets peut-être utilisée dans le cas de balises unpackOptions.

    En plus de mécanisme d'inclusion et d'exclusion, les options de dépaquetage sur une liste de dépendances peuvent également utiliser un flag filtering, dont la valeur par défaut est false. Encore une fois, cela ressemble beaucoup au mécanisme proposé par les ensembles de fichiers discuté ci-dessus. Les expressions peuvent utiliser, soit la syntaxe Maven : ${property}, soit la syntaxe Ant : @property@. Le filtrage des ressources est particulièrement intéressant pour les ensembles de dépendances. Elle permet de créer des modèles de ressources normalisés et versionnés qui peuvent être personnalisés à chaque intégration à un assembly. Une fois que vous maîtrisez cette fonctionnalité de filtrage, que vous avez dépaqueté les dépendances de ressources partagées, vous serez en mesure de commencer à éliminer et centraliser certaines ressources partagées.

    14.5.4.7. Résumé des ensembles de dépendances

    Au final, il est important de mentionner que les ensembles de dépendances supportent les mêmes options de configuration fileMode et directoryMode que les ensembles de fichiers. Cependant, vous devrez vous rappeler que l'option directoryMode ne sera utilisée que si les dépendances sont dépaquetées.