Variables spéciales

• Certaines variables spécialement définies et référençables ne sont pas incluses dans le modèle de projet.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...
  
  <build>
    ...
          <target>
            <echo>project.basedir = ${project.basedir}</echo>
            <echo>project.baseUri = ${project.baseUri}</echo>
            <echo>maven.build.timestamp = ${maven.build.timestamp}</echo>
          </target>
    ...
  </build>
</project>

Résultat d'exécution

     [echo] project.basedir = F:\tmp\maven\hello
     [echo] project.baseUri = file:///F:/tmp/maven/hello/
     [echo] maven.build.timestamp = 2020-03-04T13:45:10Z

• Les trois suivantes sont des variables implicitement définies comme des ** Variables spéciales **.
  • project.basedir
• Dossier du projet lui-même
  • project.baseUri --project.basedir représenté par l'URI
  • maven.build.timestamp
• Horodatage d'exécution (UTC)

Spécifiez le format de l'horodatage

• En déclarant la propriété maven.build.timestamp.format, vous pouvez spécifier le format de maven.build.timestamp de manière arbitraire. ―― Le format du format suit SimpleDateFormat.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <properties>
    <maven.build.timestamp.format>yyyy/MM/dd HH:mm:ss</maven.build.timestamp.format>
  </properties>
  
  <build>
    ...
            <echo>maven.build.timestamp = ${maven.build.timestamp}</echo>
    ...
  </build>
</project>

Résultat d'exécution

     [echo] maven.build.timestamp = 2020/03/04 13:49:49+00:00

Propriété

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <properties>
    <foo>FOO!!</foo>
    <fizz.buzz>FIZZ.BUZZ!?</fizz.buzz>
    <hoge-fuga>HOGE-FUGA??</hoge-fuga>
  </properties>
  
  <build>
    ...
            <echo>foo = ${foo}</echo>
            <echo>fizz.buzz = ${fizz.buzz}</echo>
            <echo>hoge-fuga = ${hoge-fuga}</echo>
            <echo>FOO = ${FOO}</echo>
    ...
  </build>
</project>

Résultat d'exécution

     [echo] foo = FOO!!
     [echo] fizz.buzz = FIZZ.BUZZ!?
     [echo] hoge-fuga = HOGE-FUGA??
     [echo] FOO = ${FOO}

• Vous pouvez déclarer vos propres variables (propriété) dans la balise «». ---et . peuvent être inclus dans le nom --Sensible aux majuscules et minuscules

Variable d'environnement

xml.pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...
  
  <build>
    ...
            <echo>hoge = ${env.hoge}</echo>
            <echo>Hoge = ${env.Hoge}</echo>
            <echo>HOGE = ${env.HOGE}</echo>
    ...
  </build>
</project>

Résultat d'exécution(Lors de l'exécution sous Windows)

> set Hoge=Hello

> mvn antrun:run
...
     [echo] hoge = ${env.hoge}
     [echo] Hoge = ${env.Hoge}
     [echo] HOGE = Hello
...

Résultat d'exécution(Lors de l'exécution sous Linux)

$ export Hoge=Hello

$ mvn antrun:run
...
     [echo] hoge = ${env.hoge}
     [echo] Hoge = Hello
     [echo] HOGE = ${env.HOGE}

• Vous pouvez faire référence à la valeur de la variable d'environnement OS avec $ {env. Nom de la variable d'environnement} --Lors de l'exécution sous Windows, le nom de la variable ʻenv` est ** normalisé dans toutes les majuscules **
• Autrement dit, même si le nom de la variable d'environnement déclaré sous Windows est «Path», il doit être écrit en majuscules sous la forme «$ {env.PATH}» lorsqu'il est référencé sur pom.xml. ――Ce n'est qu'une histoire sous Windows, et lors de l'exécution sous Linux, spécifiez-la avec le même nom sensible à la casse. ――Eh bien, je pense qu'il est courant de déclarer les variables d'environnement dans toutes les lettres majuscules, donc si vous écrivez pom.xml dans toutes les lettres majuscules, vous n'aurez pas d'accident.

Propriétés du système

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...
  
  <properties>
    <foo.bar>foo-bar</foo.bar>
    <fizz.buzz>fizz-buzz</fizz.buzz>
  </properties>

  <build>
    ...
            <echo>java.version = ${java.version}</echo>
            <echo>java.vm.vendor = ${java.vm.vendor}</echo>
            <echo>foo.bar = ${foo.bar}</echo>
            <echo>fizz.buzz = ${fizz.buzz}</echo>
    ...
  </build>
</project>

Résultat d'exécution

> mvn antrun:run -Dfoo.bar=FOO-BAR
...
     [echo] java.version = 11.0.6
     [echo] java.vm.vendor = AdoptOpenJDK
     [echo] foo.bar = FOO-BAR
     [echo] fizz.buzz = fizz-buzz

• Vous pouvez vous référer aux propriétés système Java (valeurs qui peuvent être obtenues avec System.getProperties ()) comme avec $ {nom de la propriété système}. --Si une propriété avec le même nom est déclarée dans ` '', la valeur spécifiée dans la propriété système est prioritaire.

Dépôt

• L'un des composants importants de Maven est le ** Repository ** --Maven stocke et gère les artefacts du projet créé dans le référentiel.
• L'artefact réel est généralement un fichier jar créé lors de la construction du projet.

Dépôt central

--Il existe deux types de référentiels

• Dépôt local
• Référentiel distant --Il existe un référentiel distant utilisé par défaut appelé Central Repository (https://repo.maven.apache.org/maven2). -Si vous ouvrez le lien ci-dessus avec un navigateur, vous pouvez voir que divers sous-répertoires existent. --Si vous suivez correctement le répertoire, vous atteindrez enfin le répertoire où se trouve le fichier jar. --Par exemple, this a le noyau Spring Framework ver 5.2.4.RELEASE placé. Devenez un annuaire
• Comme vous pouvez le voir, le référentiel central contient divers artefacts OSS du monde entier.
• Le référentiel central est géré par une société appelée Sonatype.
• Tout le monde peut publier son OSS dans le référentiel central en postulant (gratuitement)
• Cependant, l'application est en anglais
• L'unité d'application est pour chaque groupId --Si vous recherchez "Maven Central Repository Publishing Procedure", vous trouverez divers articles de commentaires.
• Comme il est difficile de rechercher le référentiel central ouvert directement dans le navigateur, utilisez généralement un site de recherche tel que Maven Repository: Search / Browse / Explore.
• Sinon, reportez-vous aux informations écrites sur la page officielle de la bibliothèque que vous souhaitez utiliser.

Résolution des dépendances

• L'une des fonctionnalités puissantes de Maven est la résolution des dépendances. --Dans pom.xml, les artefacts utilisés par le projet peuvent être définis comme dépendances comme suit:

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
    </dependency>
  </dependencies>
</project>

--<dependency>sous<dependencies>pointe vers un artefact

• Si vous le déclarez ainsi, Maven téléchargera automatiquement les artefacts déclarés avec ` '' depuis le référentiel distant lorsque vous construirez le projet et les ajouterez à votre chemin de classe. ―― En d'autres termes, vous pouvez éviter de supprimer la bibliothèque à la main.
• De plus, les artefacts stockés dans le référentiel contiennent également leur propre pom.xml. --S'il y a plus de ` '' dans le pom.xml de l'artefact spécifié dans le projet, Maven téléchargera également automatiquement ces artefacts dépendants. ―― En d'autres termes, c'est un mécanisme qui résout toutes les dépendances à l'expression Imozuru. --Maven facilite la gestion des bibliothèques dépendantes grâce à ce mécanisme. --Apache Ant, le prédécesseur de Maven, était très pénible car il devait gérer les dépendances manuellement.
• Ce mécanisme est également utilisé chez Gradle, un retardataire de Maven.

Dépôt local

• Les artefacts et les méta-informations (comme pom.xml) téléchargés à partir d'un référentiel distant sont mis en cache localement sur la machine exécutant Maven.
• Cette destination de cache est appelée ** référentiel local ** ――Si vous accédez au référentiel distant à chaque fois que vous construisez, cela prendra beaucoup de temps et vous ne pourrez pas construire dans un environnement où le réseau n'est pas disponible.
• Par conséquent, Maven est censé rechercher d'abord le référentiel local.
• Trouve le référentiel distant si l'artefact souhaité n'existe pas dans le référentiel local.
• Si vous trouvez un artefact dans un référentiel distant, téléchargez-le et enregistrez-le dans votre référentiel local.
• Cela vous permet de créer un projet sans accès au réseau, car il vous suffit de vous référer au référentiel local à partir de la deuxième fois.
• L'emplacement du référentiel local est par défaut % USERPROFILE% \ .m2 \ repository
• Pour Linux OS, $ HOME / .m2 / repository
• Les objets mis en cache dans le référentiel local resteront si rien n'est fait
• À moins qu'il n'y ait une raison telle que le manque d'espace disque, il n'est pas nécessaire de l'effacer.

Dépôt privé

• Vous pouvez créer votre propre référentiel distant à l'aide d'une application OSS appelée Nexus Repository OSS. --Nexus est développé par Sonatype, qui gère le référentiel central. --Il existe une version payante et une version OSS gratuite
• Par exemple, si vous avez un artefact que vous souhaitez partager uniquement au sein de votre entreprise, vous pouvez facilement l'utiliser comme référentiel privé en créant un serveur Nexus dans l'intranet.
• Le référentiel distant à utiliser peut être spécifié dans pom.xml comme suit:
• Le nom de l'hôte et le numéro de port doivent être ajustés en fonction de l'environnement réel

Pom lorsqu'un référentiel distant est spécifié.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <repositories>
    <repository>
      <id>my-private-repository</id>
      <name>My Private Repository</name>
      <url>http://private.repository.host/repository</url>
      <layout>default</layout>
    </repository>
  </repositories>
</project>

• De plus, Nexus agit également en tant que proxy pour d'autres référentiels distants. ――Par exemple, supposons que vous ayez la configuration suivante --Construire le référentiel Nexus en tant que proxy pour le référentiel central --Définir le référentiel Nexus comme référentiel distant dans pom.xml
• Si le projet a des artefacts dépendants, Maven recherchera d'abord le référentiel local.
• S'il ne se trouve pas dans le référentiel local, recherchez le référentiel Nexus que vous avez spécifié comme référentiel distant. --Nexus recherche le référentiel central s'il ne se trouve pas dans le référentiel Nexus --Et il renvoie les artefacts téléchargés depuis le référentiel central vers Maven.
• À ce stade, le référentiel Nexus met en cache en interne les artefacts téléchargés à partir du référentiel central.
• Si une requête de recherche pour le même artefact arrive, elle renverra l'artefact mis en cache. ―― Cela vous permettra de réduire le trafic réseau, ou même si Internet n'est pas connecté en raison d'une sorte de panne, vous pouvez résoudre la dépendance en vous connectant au référentiel Nexus dans l'intranet.

** Image proxy **

Plug-in (basique)

Dans Maven, tout le traitement est effectué par ** Plugin **.

Par exemple, le processus de compilation du code source Java est fourni par maven-compiler-plugin.

Vous pouvez trouver une liste des plugins de base fournis par le projet Maven lui-même sur Maven - Plugins disponibles.

Objectif du plugin

• Les tâches (processus) individuelles définies dans le plug-in sont appelées ** Objectif **.
• Reportez-vous à la documentation de chaque plug-in pour connaître les objectifs du plug-in que vous souhaitez utiliser. --Objectifs définis dans maven-jdeps-plugin - jdkinternals - test-jdkinternals --Objectifs définis dans maven-jar-plugin - jar - test-jar

Comment exécuter un objectif

Il existe deux manières principales d'exécuter les objectifs d'un plug-in.

1. Spécifiez directement sur la ligne de commande et exécutez
2. Exécuter en association avec la phase

La méthode de liaison à la deuxième phase est mise de côté et la méthode de spécification directe de 1 est confirmée en premier.

Spécification de nom complet

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

Exécutez le plug-in jdeps

> mvn org.apache.maven.plugins:maven-jdeps-plugin:3.1.2:jdkinternals
...
classes -> java.base
   example          -> java.io            java.base
   example          -> java.lang          java.base
...

• Quelque peu de longs arguments sont passés à la commande mvn
• Ceci spécifie le nom complet et le nom de l'objectif du précédent maven-jdeps-plugin. --Dans le format, cela ressemble à <nom complet>: <nom de l'objectif> --<nom complet>est ici ʻorg.apache.maven.plugins: maven-jdeps-plugin: 3.1.2, -- <nom de l'objectif> devient jdkinternals`
• Si vous spécifiez un nom qualifié complet, le fichier jar du plug-in est extrait du référentiel en fonction de ces informations et l'objectif est exécuté.

spécification de préfixe (lorsqu'il n'y a pas de paramètre de plug-in)

―― Comme il est difficile de saisir le nom complet à chaque fois, vous pouvez également omettre la description suivante.

Si omis

> mvn jdeps:jdkinternals
...
classes -> java.base
   example          -> java.io            java.base
   example          -> java.lang          java.base
...

• Voici comment spécifier le format <préfixe>: <nom de l'objectif>
• Qu'il s'agisse d'une spécification de nom complet ou d'une spécification de préfixe se distingue par le nombre de deux-points (:) [^ 4]
• S'il y a trois :, spécifiez avec le nom complet groupId: artifactId: version: goal. --S'il y a deux :, spécifiez groupId: artifactId: goal sans le numéro de version. --S'il n'y a qu'un seul :, spécifiez avec le préfixe prefix: goal --Si le préfixe est spécifié, le nom complet sera résolu comme suit.
• Tout d'abord, laissez groupdId être l'un des suivants:
  • org.apache.maven.plugin
  • org.codehaus.mojo
• Ensuite, regardez les métadonnées (maven-metadata.xml) pour chaque groupId
• maven-metadata.xml dans org.apache.maven.plugin
• org.codehaus.mojo maven-metadata.xml
• En regardant le contenu de maven-metadata.xml, vous pouvez voir que la correspondance du préfixe est répertoriée pour chaque ʻartifactId`.

xml:org.apache.maven.plugin maven-metadata-xml

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <plugins>
    <plugin>
      <name>Apache Maven ACR Plugin</name>
      <prefix>acr</prefix>
      <artifactId>maven-acr-plugin</artifactId>
    </plugin>
    ...
    <plugin>
      <name>Apache Maven JDeps Plugin</name>
      <prefix>jdeps</prefix>
      <artifactId>maven-jdeps-plugin</artifactId>
    </plugin>
    ...
  </plugins>
</metadata>

--Trouvez une correspondance dans ce maven-metadata.xml qui correspond au préfixe spécifié sur la ligne de commande, et définissez ce <artifactId> sur ʻartifactId`.

• Puisque le préfixe spécifié sur la ligne de commande est jdeps, maven-jdeps-plugin devient ʻartifactId`.
• Ensuite, vérifiez les métadonnées (maven-metadata.xml) pour chaque ʻartifactId`
• maven-metadata.xml de maven-jdeps-plugin

maven-jdeps-plugin maven-metadata.xml

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jdeps-plugin</artifactId>
  <versioning>
    <latest>3.1.2</latest>
    <release>3.1.2</release>
    <versions>
      <version>3.0.0</version>
      <version>3.1.0</version>
      <version>3.1.1</version>
      <version>3.1.2</version>
    </versions>
    <lastUpdated>20190619052916</lastUpdated>
  </versioning>
</metadata>

--Définissez la valeur définie dans la version finale (<release>) sur version --S'il n'y a pas de version finale, laissez la dernière version (<latest>) [^ 5] être version. --Les groupId, ʻartifactId, versiondéterminés ci-dessus sont des noms complets. -groupId:org.apache.maven.plugin -artifactId:maven-jdeps-plugin -version:3.1.2`

[^ 4]: Strictement parlant, une spécification telle que compiler :::: compile est également considérée comme une spécification de préfixe, mais ici le nombre de deux-points est utilisé par souci de clarté (pour plus de détails, [implémentation MojoDescriptorCreator] Voir](https://github.com/apache/maven/blob/maven-3.6.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoDescriptorCreator.java#L141) )

[^ 5]: «» est la dernière version de la version, tandis que «» fait référence à la dernière version, y compris les instantanés.

Définir explicitement le plug-in

-Dans la méthode de ↑, la version du plug-in est décidée en fonction des métadonnées.

• Probablement la dernière version sera utilisée lorsqu'une nouvelle version sortira, mais si le mouvement ne peut pas être corrigé, la construction peut devenir instable.
• Par conséquent, normalement, la version du plug-in utilisé pour chaque projet est fixe.
• Dans le cas de ↑, le préfixe ne peut être spécifié que lorsque groupId est soit ʻorg.apache.maven.plugin soit ʻorg.codehaus.mojo [^ 6]
• Si vous souhaitez utiliser un plug-in de groupId autre que ceux-ci en spécifiant un préfixe, vous devez définir le plug-in explicitement.

[^ 6]: Strictement parlant, vous pouvez ajouter le groupId à rechercher par <pluginGroups> ʻin settings.xml` (Référence: Introduction to Plugin Prefix Resolution guides / introduction / introduction-to-plugin-prefix-mapping.html # Configuring_Maven_to_Search_for_Plugins))

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.asciidoctor</groupId>
        <artifactId>asciidoctor-maven-plugin</artifactId>
        <version>1.5.8</version>
      </plugin>
    </plugins>
  </build>
</project>

--Les plugins individuels sont définis avec la balise <plugin> --<plugin>est répertorié sous<build> <plugins> --Spécifiez le nom complet du plug-in avec <groupId>, <artifactId>, <version>

• Ici, Asciidoctor Maven Plugin est défini.
• Ce paramètre verrouille la version de ʻasciidoctor-mavne-pluginsur1.5.8`.

asciidoctor-maven-Plug-in en cours d'exécution

> mvn asciidoctor:process-asciidoc
...
[INFO] BUILD SUCCESS
...

Résolution de la spécification du préfixe (si le plug-in est spécifié)

-Lorsque le plug-in est spécifié par <plugin> comme dans ↑, la méthode de résolution du nom complet à partir de la spécification de préfixe change un peu.

• Tout d'abord, Maven vérifie le plugin.xml de chaque plug-in explicitement défini dans pom.xml.
• Habituellement, plugin.xml est stocké sous META-INF / maven dans le fichier jar du plugin. --Par exemple, le plugin.xml de ʻasciidoctor-mavne-plugin` ressemble à ceci:

asciidoctor-maven-plugin plugin.xml

<?xml version="1.0" encoding="UTF-8"?>

<!-- Generated by maven-plugin-tools 3.5 on 2019-03-30 -->

<plugin>
  <name>Asciidoctor Maven Plugin and Doxia Parser</name>
  <description>Asciidoctor Maven Plugin and Doxia Parser (for Maven Site integration)</description>
  <groupId>org.asciidoctor</groupId>
  <artifactId>asciidoctor-maven-plugin</artifactId>
  <version>1.5.8</version>
  <goalPrefix>asciidoctor</goalPrefix>
  <isolatedRealm>false</isolatedRealm>
  <inheritedByDefault>true</inheritedByDefault>
  ...

• La chose importante ici est la valeur définie dans <goalPrefix>
• Les plugins groupId et ʻartifactIddont la valeur est égale au préfixe spécifié sur la ligne de commande sont adoptés. --Enfin,version est déterminée comme suit --Si spécifié dans pom.xml, cette version sera adoptée --Si non spécifié, il est déterminé à partir des métadonnées (maven-metadata.xml) pour chaque ʻartifactId (même méthode que lorsqu'aucun plug-in n'est spécifié).

Relation entre artifactId et prefix

--Dans l'explication jusqu'à présent, on peut voir que ʻartifactId` et le préfixe sont essentiellement sans rapport.

• Le préfixe est déterminé par <prefix> dans maven-metadata.xml ou <goalPrefix> ʻin plugin.xml. Cependant, dans les plug-ins qui existent réellement, ʻartifactId et prefix ont la relation suivante. --Pour les plug-ins officiels fournis par le projet Maven --Si ʻartifactId est maven-XXX-plugin, XXX est le préfixe --Pour les autres plug-ins --Si ʻartifactId est XXX-maven-plugin, XXX est le préfixe ―― Ce sont les résultats de ces règles de dénomination recommandées, et cela ne signifie pas que vous ne pouvez pas créer un plug-in sans ce nom.
• Si vous voulez le faire, vous pouvez également créer un plug-in avec ʻartifactId` qui est complètement différent de cette règle de dénomination.
• ** Cependant, le nom maven-XXX-plugin est destiné à indiquer qu'il s'agit du plug-in officiel de Maven, donc soyez prudent car l'utilisation non officielle de ce nom entraînera une contrefaçon de marque ** - Important Notice: Plugin Naming Convention and Apache Maven Trademark
• Une dénomination inhabituelle ne fera que semer la confusion chez les utilisateurs et il n'y a aucun mérite, donc si vous créez votre propre plug-in, il est prudent d'utiliser ʻartifactId comme XXX-maven-plugin à moins qu'il n'y ait une raison particulière. «Ainsi, ʻartifactId et le préfixe ne sont pas essentiellement liés, mais il est normal de penser qu'ils sont liés dans la pratique (je pense). --Ainsi, si ʻartifactId est foo-maven-plugin, vous pouvez considérer le préfixe comme foo` (je pense)
• Inversement, si le préfixe est foo, ʻartifactId peut être considéré comme foo-maven-plugin` (s'il ne s'agit pas d'un plugin fourni par le projet Maven).

Paramètres du plug-in (paramètres)

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>Hello World!!</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn antrun:run
...
main:
     [echo] Hello World!!
...

• Les paramètres du plug-in (** paramètres **) peuvent être décrits avec la balise <configuration> sous <plugin>
• Les balises qui peuvent être spécifiées sous «» sont différentes pour chaque objectif de plug-in.
• Ici, nous utilisons un plugin appelé maven-antrun-plugin --Ce plugin a pour objectif run
• Vous pouvez voir que la page de description de l'objectif run liste les paramètres qui peuvent être spécifiés avec <configuration>.
• Pour un plug-in avec plusieurs objectifs, les paramètres spécifiés dans ` 'seront appliqués à tous les objectifs.

Vérifiez la description de la fiche

• Vous pouvez vérifier les objectifs de chaque plug et quels paramètres peuvent être spécifiés en regardant la page d'explication de chaque plug.
• Cependant, si vous rencontrez des difficultés pour ouvrir chaque page, vous pouvez la vérifier avec maven-help-plugin.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-help-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-antrun-plugin</artifactId>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn help:describe
...
Name: Apache Maven AntRun Plugin
Description: Runs Ant scripts embedded in the POM
Group Id: org.apache.maven.plugins
Artifact Id: maven-antrun-plugin
Version: 1.8
Goal Prefix: antrun

This plugin has 2 goals:

antrun:help
  Description: Display help information on maven-antrun-plugin.
    Call mvn antrun:help -Ddetail=true -Dgoal=<goal-name> to display parameter
    details.

antrun:run
  Description: Maven AntRun Mojo.
    This plugin provides the capability of calling Ant tasks from a POM by
    running the nested Ant tasks inside the <tasks/> parameter. It is
    encouraged to move the actual tasks to a separate build.xml file and call
    that file with an <ant/> task.

For more information, run 'mvn help:describe [...] -Ddetail'
...

-En exécutant l'objectif décrire, vous pouvez décrire le plugin spécifié par <configuration>. Peut être confirmé --<groupId>et<artifactId>permettent au plug-in d'être identifié comme maven-antrun-plugin. -- describe Comme vous pouvez le voir sur la page de description de l'objectif, vous pouvez affiner l'objectif avec <goal> et afficher les détails (paramètres pouvant être spécifiés pour chaque objectif) avec <detail>.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-help-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-antrun-plugin</artifactId>
          <goal>run</goal>
          <detail>true</detail>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn help:describe
...
antrun:run
  Description: Maven AntRun Mojo.
    ...
  Implementation: org.apache.maven.plugin.antrun.AntRunMojo
  Language: java

  Available parameters:

    ...

    target
      The XML for the Ant target. You can add anything you can add between
      <target> and </target> in a build.xml.

    ...
...

-Bien que l'exemple de ↑ soit omis, tous les paramètres sont affichés avec des explications.

Spécifié dans les propriétés du système

• Les paramètres spécifiés dans <configuration> de help: describe peuvent également être spécifiés à partir des propriétés système.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-help-plugin</artifactId>
        <version>3.2.0</version>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn help:describe -Dplugin=antrun
...
Name: Apache Maven AntRun Plugin
Description: Runs Ant scripts embedded in the POM
Group Id: org.apache.maven.plugins
Artifact Id: maven-antrun-plugin
Version: 1.8
Goal Prefix: antrun

This plugin has 2 goals:

antrun:help
  Description: Display help information on maven-antrun-plugin.
    ...

antrun:run
  Description: Maven AntRun Mojo.
    ...

For more information, run 'mvn help:describe [...] -Ddetail'
...

---Dplugin = antrun est spécifié comme propriété système lors de l'exécution de Maven

• Voir Documentation pour une description du paramètre plugin.
• Comme vous pouvez le voir, certains paramètres d'objectif vous permettent de transmettre des valeurs dans les propriétés système.
• Tous les paramètres ne peuvent pas être spécifiés dans les propriétés système
• Il est possible de vérifier si un paramètre peut être spécifié dans une propriété système en vérifiant si le document du paramètre contient ** Propriété utilisateur **. --Par exemple, dans la documentation des paramètres du plugin, il est dit ʻUser Property: plugin`. Peut être confirmé
• Cela signifie que vous pouvez spécifier une valeur avec une propriété nommée plugin.
• Le nom du paramètre et le nom de la propriété ne correspondent pas toujours ** --plugin correspond juste, comme antrun skip Certains ne le sont pas
• Ici, ** propriétés ** signifie que vous pouvez spécifier non seulement les propriétés système mais aussi ` '' sur pom.xml.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <properties>
    <plugin>jdeps</plugin>
  </properties>

  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-help-plugin</artifactId>
        <version>3.2.0</version>
      </plugin>
    </plugins>
  </build>
</project>

--Dans <properties>, jdeps est défini dans plugin.

Résultat de l'exécution (lorsque le plugin n'est pas spécifié dans les propriétés système)

> mvn help:describe
...
Name: Apache Maven JDeps Plugin
Description: The JDeps Plugin uses the jdeps tool to analyze classes for
  internal API calls.
Group Id: org.apache.maven.plugins
Artifact Id: maven-jdeps-plugin
Version: 3.1.2
Goal Prefix: jdeps
...

Résultat de l'exécution (lorsque le plugin est spécifié dans les propriétés système)

> mvn help:describe -Dplugin=antrun
...
Name: Apache Maven AntRun Plugin
Description: Runs Ant scripts embedded in the POM
Group Id: org.apache.maven.plugins
Artifact Id: maven-antrun-plugin
Version: 1.8
Goal Prefix: antrun
...

--Si aucune propriété système n'est spécifiée, la valeur spécifiée dans <properties> (jdeps) est adoptée. --Si vous spécifiez une propriété système, cette valeur (ʻantrun`) est adoptée.

Cycle de vie et phase

――Même si vous dites "construire" en un mot, son contenu comprend divers processus. --Par exemple, pour construire un programme Java simple, le traitement suivant peut être envisagé.

1. Compilez le code source
2. Collectez les fichiers de ressources
3. Compilez le code de test
4. Collectez les fichiers de ressources pour les tests
5. Exécutez le code de test
6. Empaquetez les résultats de la compilation et les fichiers de ressources dans une archive telle qu'un fichier jar.
7. Stockez l'archive en place

• À Maven, chacun de ces processus est appelé ** Phase **. --Et l'ensemble des phases s'appelle ** Cycle de vie **

Cycle de vie intégré

--Maven a les trois cycles de vie suivants en standard. - default - clean - site

cycle de vie par défaut

• Le cycle de vie par défaut définit le cycle de vie de la création d'un projet à son déploiement.
• Le cycle de vie par défaut comprend les phases suivantes:
  1. validate
  2. initialize
  3. generate-sources
  4. process-sources
  5. generate-resources
  6. process-resources
  7. compile
  8. process-classes
  9. generate-test-sources
  10. process-test-sources
  11. generate-test-resources
  12. process-test-resources
  13. test-compile
  14. process-test-classes
  15. test
  16. prepare-package
  17. package
  18. pre-integration-test
  19. integration-test
  20. post-integration-test
  21. verify
  22. install
  23. deploy

cycle de vie propre

• Le cycle de vieclean définit un cycle de vie pour supprimer les artefacts du projet --clean Le cycle de vie comprend les phases suivantes
  1. pre-clean
  2. clean
  3. post-clean

cycle de vie du site

• Le cycle de vie du site définit le cycle de vie de la génération du site Web du projet
• Le cycle de vie du «site» comprend les phases suivantes:
  1. pre-site
  2. site
  3. post-site
  4. site-deploy

Relation entre les phases et les objectifs du plug-in

• Chaque phase du cycle de vie est associée aux objectifs du plug-in qui s'exécute dans cette phase.

propre, site Pour le cycle de vie

--Par exemple, dans le cycle de vie «propre» et le cycle de vie «site», les objectifs sont liés comme suit:

** plug-in propre **

** plug-in de site **

• Autrement dit, l'exécution de la phase clean exécutera le but clean du maven-clean-plugin.

Pour le cycle de vie par défaut

• Dans le cas du cycle de vie «par défaut», l'association entre la phase et l'objectif n'est pas fixe.
• Les objectifs exécutés dans le cycle de vie par défaut dépendent du ** packaging ** du projet.

packaging -Packaging est une valeur de paramètre qui détermine comment empaqueter le projet, et l'une des valeurs suivantes peut être spécifiée. - pom - jar - ejb - maven-plugin - war - ear - rar --Ce packaging est spécifié sur pom.xml comme suit:

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...
  <packaging>jar</packaging>
  ...
</project>

• Ici, jar est spécifié comme emballage.
• La balise «» peut être omise dans pom.xml. --Si omis, la valeur par défaut est jar

Objectifs pour chaque emballage

-- par défaut Les objectifs associés aux phases du cycle de vie diffèrent selon l'emballage comme suit:

• À titre d'exemple, les objectifs associés à «pom» et «jar» sont les suivants:
• Le nombre de phases étant important, les phases qui ne sont associées à rien sont exclues (valider etc.)
• Pour les packages autres que ceux-ci, reportez-vous à Maven Core - Plugin Bindings for Default Lifecycle Reference.

pom

jar

Effectuer une phase

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

Lancer la phase de test

> mvn test
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello ---
...

--Phase peut être exécuté en le spécifiant dans l'argument de la commande mvn.

• Ici, j'essaye d'exécuter la phase test dans un projet dont le packaging est jar. --packaing prend la valeur par défaut jar car la description de <packaing> est omise. --Si vous spécifiez une phase et l'exécutez, toutes les phases antérieures à cette phase seront également exécutées dans l'ordre.
• Par exemple, des phases telles que «valider», «ressources-processus» et «test-compilation» sont définies avant la phase «test».
• Dans l'exemple ci-dessus, vous pouvez voir que maven-resources-plugin: resources, maven-compiler-plugin: compile, ... sont exécutés.
• Lorsqu'une phase est exécutée, tous les objectifs associés à cette phase sont exécutés. -- maven-resources-plugin: resources Le but est dans la phase resources, maven-compiler-plugin: compile Le but est lié à la phase compile

Exécuter en spécifiant plusieurs phases et objectifs

> mvn clean compiler:compile

--Plusieurs phases et objectifs peuvent être spécifiés dans la commande mvn et exécutés.

• Dans ce cas, l'ordre d'exécution est clean → compiler: compile.
• En d'autres termes, il est exécuté dans l'ordre spécifié par l'argument.

Associer des objectifs à des phases

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <phase>validate</phase>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <target>
            <echo>Hello Antrun!!</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn compile
...
[INFO] --- maven-antrun-plugin:1.8:run (default) @ hello ---
[INFO] Executing tasks

main:
     [echo] Hello Antrun!!
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...

--Tout objectif peut être lié à n'importe quelle phase

• La phase et l'objectif sont liés à dans les paramètres du plug-in. --Spécifiez la phase avec <phase> et spécifiez l'objectif à lier avec <goals> <goal>
• Ici, le but «run» de «maven-antrun-plugin» est associé à la phase «validate».
• Comme vous pouvez le voir à partir de la structure <goals> <goal>, il est possible de lier plusieurs objectifs du même plug-in à une phase.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jdeps-plugin</artifactId>
        <version>3.2.6</version>
        <executions>
          <execution>
            <phase>verify</phase>
            <goals>
              <goal>jdkinternals</goal>
              <goal>test-jdkinternals</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn verify
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello ---
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello ---
...
[INFO] --- maven-jdeps-plugin:3.1.2:jdkinternals (default) @ hello ---
...
[INFO] --- maven-jdeps-plugin:3.1.2:test-jdkinternals (default) @ hello ---

• Lier jdkinternals et test-jdkinternals de maven-jdeps-plugin à la phase verify --Si plusieurs objectifs sont liés à une phase, ces objectifs seront exécutés dans l'ordre déclaré sur pom.xml [^ 7]
• En d'autres termes, dans le cas du réglage ↑, il est exécuté dans l'ordre de jdkinternals → test-jdkinternals.
• Vous pouvez changer l'ordre d'exécution en changeant l'ordre des balises «».

Lien vers plusieurs phases

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <id>foo</id>
            <phase>validate</phase>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
          <execution>
            <id>bar</id>
            <phase>compile</phase>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <target>
            <echo>Hello Antrun!!</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn compile
...
[INFO] --- maven-antrun-plugin:1.8:run (foo) @ hello ---
...
     [echo] Hello Antrun!!
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-antrun-plugin:1.8:run (bar) @ hello ---
...
     [echo] Hello Antrun!!
...

--Si vous écrivez plusieurs balises <execution> '', vous pourrez lier des objectifs à plusieurs phases. --Si vous spécifiez plus d'un «<execution>», vous devez également spécifier la balise «<id>». --Définissez sur une valeur unique qui peut identifier le<exécution> --Cette valeur est sortie sur la console à l'exécution ((foo)partie demaven-antrun-plugin: 1.8: run (foo)) --Il est utile pour le débogage lorsque la construction ne se passe pas bien car ce sont des informations pour identifier quelle <exécution> 'a été exécutée. ――Par conséquent, il est préférable de donner un nom descriptif facile à identifier.

Défini pour chaque exécution

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <id>foo</id>
            <phase>validate</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <target>
                <echo>VALIDATE!!</echo>
              </target>
            </configuration>
          </execution>
          <execution>
            <id>bar</id>
            <phase>compile</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <target>
                <echo>COMPILE!!</echo>
              </target>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn compile
...
[INFO] --- maven-antrun-plugin:1.8:run (foo) @ hello ---
...
     [echo] VALIDATE!!
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-antrun-plugin:1.8:run (bar) @ hello ---
...
     [echo] COMPILE!!
...

• La qui décrit la définition de l'objectif peut également être spécifiée pour chaque <exécution>. ―― Cela permet de diviser les paramètres pour chaque phase spécifique.

Un identifiant spécial qui est adopté lorsque l'objectif est exécuté directement

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <target>
                <echo>Hello @ default-cli</echo>
              </target>
            </configuration>
          </execution>
          <execution>
            <id>validate-phase</id>
            <phase>validate</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <target>
                <echo>Hello @ validate-phase</echo>
              </target>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn antrun:run
...
     [echo] Hello @ default-cli
...

> mvn validate
...
     [echo] Hello @ validate-phase
...

--Si vous exécutez le but directement, ʻid est par défaut default-cli`

• Par conséquent, si vous définissez <execution> <id> avec cette valeur, vous pouvez décrire le paramètre qui est appliqué uniquement lorsque l'objectif est exécuté directement.

Exécuter en spécifiant l'id

--Depuis 3.3.1 de Maven, il est possible d'exécuter le but en spécifiant «» de «».

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <target>
                <echo>Hello default-cli!!</echo>
              </target>
            </configuration>
          </execution>
          <execution>
            <id>foo</id>
            <configuration>
              <target>
                <echo>Hello Foo!!</echo>
              </target>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

• Les deux «», «default-cli» et «foo» définissent «».

Résultat d'exécution

> mvn antrun:run
...
     [echo] Hello default-cli!!

> mvn antrun:run@foo
...
     [echo] Hello Foo!!

--ʻAntrun: Si vous exécutez uniquement avec run, default-clisera mieux exécuté -En suivant la spécification de l'objectif avec@ , comme ʻantrun: run @ foo, le <execution> du ` 'spécifié est exécuté.

Phase par défaut

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-checkstyle-plugin</artifactId>
        <version>3.1.1</version>
        <executions>
          <execution>
            <goals>
              <goal>check</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Résultat d'exécution

> mvn verify
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello ---
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello ---
...
[INFO] --- maven-checkstyle-plugin:3.1.1:check (default) @ hello ---

• Ajout de maven-checkstyle-plugin pour exécuter la phase verify --Dans pom.xml, seul « check </ goal>» est spécifié dans «», pas «».
• Cependant, si vous regardez le résultat de l'exécution, vous pouvez voir que le but check est exécuté dans la phase verify.
• Les objectifs peuvent définir les phases qui leur sont associées par défaut. --Si vous regardez la page de description de l'objectif de vérification, vous pouvez voir que la phase par défaut est «verify». Reconnaître --Si la phase n'est pas spécifiée dans <exécution>, elle sera exécutée dans la phase associée à ce défaut.
• Si un objectif n'est associé à aucune phase, cet objectif ne peut pas être activé à moins qu'il ne soit spécifié directement sur la ligne de commande.

Spécifier la version de la fiche

• Le plug-in peut être utilisé dans une certaine mesure sans le configurer explicitement avec <plugin> -Certains plugins de base (tels que maven-compiler-plugin) sont automatiquement appliqués en fonction des paramètres d'empaquetage --Si un préfixe est spécifié, groupId, ʻartifactId, version` seront automatiquement résolus.
• Si cela fonctionne sans aucun réglage, j'ai l'impression que vous n'avez pas à écrire <plugin>.
• Cependant, la méthode d'exécution sans paramétrer «» peut changer la version du plug-in à chaque fois qu'il est exécuté.
• Par exemple, le plug-in qui est automatiquement défini par l'empaquetage peut changer en fonction de la version de Maven. --Par exemple, vous pouvez vérifier la version du plug-in défini dans 3.6.3 à ici.
• Si vous n'avez pas la même version de Maven que celle utilisée par vos développeurs, les résultats de la compilation peuvent varier d'un développeur à l'autre.
• (En premier lieu, la version du plug-in par défaut est ancienne)
• De plus, la version du plug-in qui est résolue en spécifiant le préfixe est fondamentalement la dernière du référentiel. —— Encore une fois, si la dernière heure d'exécution change, les résultats peuvent changer. ―― Par conséquent, il est fondamentalement bon de spécifier la version du plug-in à utiliser même si vous pensez que c'est gênant. --Cependant, l'exemple pom.xml décrit ici peut omettre les paramètres du plug-in pour les raisons suivantes. «Lorsque la quantité de description augmente, je me sens mal à l'aise à lire. --Je ne peux pas faire attention à la partie nécessaire (la partie que j'essaie d'expliquer)

Relation parent-enfant du projet

――Vous pouvez avoir une relation parent-enfant dans le projet

Structure des dossiers

|-pom.xml
`-child/
  `-pom.xml

--Mettez le pom.xml du projet parent dans le dossier supérieur et le pom.xml du projet enfant dans le dossier child.

/pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>artifactId = ${project.artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--Dans le projet parent pom.xml, vous devez spécifier pom pour <packaging>

/child/pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child</artifactId>
</project>

--Dans le projet enfant pomx.ml, utilisez <parent> pour spécifier le parent --<parent>spécifie groupId, ʻartifactId, version` pour identifier le POM parent --Dans un projet de relation parent-enfant, le POM enfant hérite du POM parent.

• Pour cette raison, les paramètres non décrits dans le fichier pom.xml enfant seront hérités des paramètres du fichier pom.xml parent.
• Puisque les paramètres parents sont hérités pour «» et «», la description n'est pas nécessaire dans le fichier pom.xml enfant. --Cependant, «» doit être spécifié comme prévu.

Résultat de l'exécution (dossier supérieur)

> mvn antrun:run
...
     [echo] artifactId = parent

Résultat de l'exécution (dossier enfant)

> mvn antrun:run
...
     [echo] artifactId = child

• Puisque le réglage de <plugins> est également hérité, l'ensemble de plug-ins ʻantrun` dans le projet parent peut également être utilisé dans le projet enfant.

Comment résoudre le projet parent

--Parent pom.xml défini avec ` '' est recherché dans l'ordre suivant:

1. Si «» est spécifié, reportez-vous à pom.xml à cet emplacement
2. Si «» n'est pas spécifié, reportez-vous à pom.xml de ** un niveau supérieur **
3. Sinon, recherchez et parcourez le référentiel (local ou distant) -Dans l'exemple de ↑, le projet parent était un au-dessus du projet enfant, donc le POM parent a été trouvé sans spécifier l'emplacement.

Spécifiez l'emplacement du projet parent

--Cependant, dans le cas d'une structure de dossiers comme ↓, il est nécessaire de spécifier le chemin avec <relativePath>.

Structure des dossiers

|-parent/
| `-pom.xml
`-child/
  `-pom.xml

• "parent" et "enfant" sont côte à côte et pom.xml du projet parent n'existe pas au-dessus du projet enfant.
• Si vous exécutez Maven dans un projet enfant dans cet état, vous obtiendrez l'erreur suivante:

Résultat de l'exécution (projet enfant)

> mvn antrun:run
...
[FATAL] Non-resolvable parent POM for example:child:1.0.0: Failure to find example:parent:pom:1.0.0 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced and 'parent.relativePath' points at wrong local POM @ line 6, column 11
 @
...

• Pour résoudre ce problème, vous devez enregistrer le fichier jar du projet parent dans le référentiel ou spécifier l'emplacement du projet parent avec ` 'comme indiqué ci-dessous.

/child/pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
    <relativePath>../parent/pom.xml</relativePath>
  </parent>

  <artifactId>child</artifactId>
</project>

Résultat de l'exécution (projet enfant)

> mvn antrun:run
...
     [echo] artifactId = child

--Le projet parent a été trouvé et a fonctionné

Fusion de POM

--Si le POM a une relation parent-enfant, le POM parent sera fusionné dans le POM enfant.

• Voyons comment la fusion se fait

Pom parent.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <properties>
    <hoge>PARENT</hoge>
    <fuga>PARENT</fuga>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
    </dependency>
  </dependencies>

  <build>
    <resources>
      <resource>
        <directory>parent/dir</directory>
      </resource>
    </resources>

    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>hoge = ${hoge}</echo>
            <echo>fuga = ${fuga}</echo>
            <echo>piyo = ${piyo}</echo>
            <echo>dependencies[0].artifactId = ${project.dependencies[0].artifactId}</echo>
            <echo>dependencies[1].artifactId = ${project.dependencies[1].artifactId}</echo>
            <echo>resources[0].directory = ${project.build.resources[0].directory}</echo>
            <echo>resources[1].directory = ${project.build.resources[1].directory}</echo>
            <echo>plugins[0] = ${project.build.plugins[0].id}</echo>
            <echo>plugins[1] = ${project.build.plugins[1].id}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Pour la vérification, certains paramètres sont décrits afin que les paramètres puissent être affichés avec le plug-in ʻantrun`.

Enfant pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child</artifactId>

  <properties>
    <fuga>CHILD</fuga>
    <piyo>CHILD</piyo>
  </properties>

  <dependencies>
    <dependency>
      <groupId>commons-codec</groupId>
      <artifactId>commons-codec</artifactId>
      <version>1.14</version>
    </dependency>
  </dependencies>

  <build>
    <resources>
      <resource>
        <directory>child/dir</directory>
      </resource>
    </resources>

    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jdeps-plugin</artifactId>
        <version>3.1.2</version>
      </plugin>
    </plugins>
  </build>
</project>

--Il hérite du POM parent et décrit de sorte que certains paramètres se chevauchent.

Résultat de l'exécution (projet parent)

> mvn antrun:run
...
     [echo] hoge = PARENT
     [echo] fuga = PARENT
     [echo] piyo = ${piyo}
     [echo] dependencies[0].artifactId = commons-lang3
     [echo] dependencies[1].artifactId = ${project.dependencies[1].artifactId}
     [echo] resources[0].directory = parent/dir
     [echo] resources[1].directory = ${project.build.resources[1].directory}
     [echo] plugins[0] = org.apache.maven.plugins:maven-antrun-plugin:1.8
     [echo] plugins[1] = ${project.build.plugins[1].id}

• Tout d'abord, essayez de sortir chaque valeur de paramètre dans le projet parent --Bien sûr, seule la valeur définie dans le POM parent est sortie et la valeur qui n'est pas définie est sortie telle quelle sans que l'expression soit évaluée.

Résultat de l'exécution (projet enfant)

> mvn antrun:run
...
     [echo] hoge = PARENT
     [echo] fuga = CHILD
     [echo] piyo = CHILD
     [echo] dependencies[0].artifactId = commons-codec
     [echo] dependencies[1].artifactId = commons-lang3
     [echo] resources[0].directory = child/dir
     [echo] resources[1].directory = ${project.build.resources[1].directory}
     [echo] plugins[0] = org.apache.maven.plugins:maven-antrun-plugin:1.8
     [echo] plugins[1] = org.apache.maven.plugins:maven-jdeps-plugin:3.1.2

• En conséquence de la sortie dans le projet enfant, le paramètre POM enfant est adopté pour la partie qui se chevauche (<properties> <fuga> etc.) dans le paramètre de valeur unique.
• D'autre part, la partie superposée (<dependencies>, <plugins>, etc.) dans le réglage de plusieurs valeurs est basée sur le POM parent et l'élément du POM enfant est ajouté.
• Fondamentalement, les éléments à valeur unique sont écrasés et les éléments à valeurs multiples (tels que ` '') ont des éléments ajoutés.
• Cependant, il y a quelques exceptions, par exemple, <build> <resources> est un élément à valeurs multiples mais est écrasé.
• La documentation officielle indique que «» est également susceptible de fusionner, mais en réalité Écrasé --En termes de mise en œuvre, [ModelMerger](https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/java/org/apache/maven/model/merge/ModelMerger Il semble que POM soit fusionné dans une classe appelée .java)
• [MergeBuildBase_Resources ()] de cette classe (https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/java/org/apache/maven/model/merge/ ModelMerger.java # L2195) fusionne <ressources>
• Dans cette implémentation, <resource> est censée être fusionnée en plus --Mais en réalité, c'est une sous-classe de ce ModelMerger [MavenModelMerger](https://github.com/apache/maven/blob/maven-3.6.3/maven-model-builder/src/main/java/ org / apache / maven / model / merge / MavenModelMerger.java) semble fusionner --MavenModelMerger est [mergeBuildBase_Resources ()](https://github.com/apache/maven/blob/maven-3.6.3/maven-model-builder/src/main/java/org/apache/maven/model Redéfinir /merge/MavenModelMerger.java#L381) pour fusionner le contenu du POM parent uniquement si le <ressources> de la cible (POM enfant) est vide.
• En d'autres termes, si «» existe dans le POM enfant, la fusion ne sera pas effectuée et seul le contenu du POM enfant sera adopté (résultant en une opération d'écrasement). --Autre que <resources>, devez-vous jeter un œil à cette implémentation de MavenModelMerger?

Vérifiez le POM après la fusion

• Les POM ont une relation parent-enfant, et si vous avez plusieurs POM en tant que parents, vous ne pouvez pas dire l'état final simplement en regardant les POM terminaux. —— Surtout lorsque la construction ne fonctionne pas, vous voulez souvent vous assurer que les POM sont fusionnés comme prévu.
• Dans de tels cas, l'objectif effective-pom de maven-help-plugin peut être utilisé.

effective-exécuter le but pom

> mvn help:effective-pom
...
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>
  <groupId>example</groupId>
  <artifactId>child</artifactId>
  <version>1.0.0</version>
(Omis car il est long)
...

• Objectif "efficace-pom" imprime le POM final avec les informations de tous les POM parents, y compris Super POM fusionné. En regardant cela, vous pouvez voir quels sont réellement les paramètres de ce projet.

Fusionner les configurations

--Description des paramètres de plug-in <configurations> Ce qui suit n'a pas de définition de schéma fixe car les paramètres sont différents pour chaque plug-in.

• Par conséquent, la fusion de <configurations> se fait uniformément selon certaines règles. --Par exemple, si <exécution> , la définition est fixée de manière à pouvoir être identifiée par , vous pouvez donc fusionner le même . ――Cependant, les balises sous ` ne peuvent pas être identifiées de cette manière, donc on a l'impression de fusionner les balises dans la même position.
• (Je n'ai pas confirmé les spécifications exactes et la mise en œuvre, donc j'ai envie de ça) ―― Voyons comment il est fusionné avec un exemple réel

POM parent

      ...
        <configuration>
          <persons>
            <person>
              <name>Taro</name>
              <age>18</age>
            </person>
            <person>
              <name>Hanako</name>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

Enfant POM

      ...
        <configuration>
          <persons>
            <person>
              <sex>male</sex>
            </person>
            <cat>nya-</cat>
            <person>
              <name>Ayako</name>
              <age>15</age>
            </person>
            <person>
              <name>Rin</name>
              <age>12</age>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

Dans cet état, vérifiez le résultat de la fusion avec help: effective-pom.

effective-pom

      ...
        <configuration>
          <persons>
            <person>
              <sex>male</sex>
              <name>Taro</name>
              <age>18</age>
            </person>
            <cat>nya-</cat>
            <person>
              <name>Ayako</name>
              <age>15</age>
              <sex>female</sex>
            </person>
            <person>
              <name>Rin</name>
              <age>12</age>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

«C'est difficile à expliquer avec des mots, mais vous pouvez voir qu'ils sont fusionnés de manière agréable. «Probablement, s'il y a une balise avec le même nom dans la même position, il semble que le contenu soit fusionné de manière récursive.

Contrôler comment fusionner

«Je pense que même le comportement par défaut fusionnera raisonnablement bien.

• Mais si cela pose un problème, vous pouvez modifier le comportement de fusion par défaut.

POM parent

      ...
        <configuration>
          <persons>
            <person>
              <name>Taro</name>
              <age>18</age>
            </person>
            <person>
              <name>Hanako</name>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

• Le POM du parent n'a pas changé

Enfant POM

      ...
        <configuration>
          <persons>
            <person combine.self="override">
              <sex>male</sex>
            </person>
            <cat>nya-</cat>
            <person combine.children="append">
              <name>Ayako</name>
              <age>15</age>
            </person>
            <person>
              <name>Rin</name>
              <age>12</age>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

• Ajout des attributs combile.self =" override " et combine.children =" append "

effective-pom

      ...
        <configuration>
          <persons>
            <person combine.self="override">
              <sex>male</sex>
            </person>
            <cat>nya-</cat>
            <person combine.children="append">
              <name>Hanako</name>
              <sex>female</sex>
              <name>Ayako</name>
              <age>15</age>
            </person>
            <person>
              <name>Rin</name>
              <age>12</age>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

• Vous pouvez voir que la méthode fusionnée a changé uniquement pour l'élément auquel l'attribut combine. * A été ajouté. --Si vous spécifiez combine.self =" override ", les éléments du POM parent sont complètement ignorés et seuls les éléments du POM enfant sont utilisés. --Si combine.children =" append " est spécifié, l'élément du POM enfant est simplement ajouté à la fin de l'élément du POM parent.
• En utilisant ces deux attributs dans le POM enfant, vous pourrez dans une certaine mesure ajuster la méthode de fusion. --Cependant, ces attributs ne sont effectifs que pour l'élément qui décrit cet attribut.
• Ne se propage pas aux éléments imbriqués --Si vous souhaitez modifier le comportement des éléments imbriqués, vous devez spécifier l'attribut combine. * De la même manière pour les éléments imbriqués.

Rassemblez uniquement les définitions du projet parent

• Les paramètres des projets parents sont toujours hérités par les projets enfants --Il est pratique si les paramètres sont communs à tous les projets enfants, mais si les paramètres ne sont requis que pour certains projets enfants, un héritage supplémentaire se produira. --Par conséquent, il existe une méthode pour mettre uniquement la définition dans le projet parent et l'appliquer explicitement dans le projet enfant qui souhaite utiliser la définition.

Résumer la définition du plug-in

Pom parent.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-antrun-plugin</artifactId>
          <version>1.8</version>
          <executions>
            <execution>
              <phase>validate</phase>
              <goals><goal>run</goal></goals>
              <configuration>
                <target>
                  <echo>Hello ${project.artifactId}</echo>
                </target>
              </configuration>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
</project>

--Utilisez <pluginManagement> pour rassembler les définitions de plugin dans le projet parent

• Sous ceci, vous pouvez écrire «» de la même manière qu'une définition de plug-in normale. ――Cependant, ce qui est décrit ici ne définit que les paramètres et n'est pas appliqué au projet.

Enfant 1 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child1</artifactId>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</project>

• Pour appliquer réellement à un projet, décrivez «», «» dans la définition du plug-in du projet que vous souhaitez appliquer. --Si la version est omise, celle décrite dans ` '' sera utilisée. --Il est également possible d'ajouter des paramètres individuels dans le projet enfant

Enfant 2 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child2</artifactId>
</project>

―― Cela n'applique aucun plug-in

Résultat de l'exécution (enfant 1)

> mvn validate
...
[INFO] ---------------------------< example:child1 >---------------------------
[INFO] Building child1 1.0.0
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-antrun-plugin:1.8:run (default) @ child1 ---
[INFO] Executing tasks

main:
     [echo] Hello child1
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

--Le plug-in est appliqué avec les paramètres définis dans le POM parent.

Résultat de l'exécution (enfant 2)

> mvn validate
...
[INFO] ---------------------------< example:child2 >---------------------------
[INFO] Building child2 1.0.0
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

• Aucun plug-in appliqué

Résumer les définitions de dépendance

Pom parent.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>2.6</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
    </dependency>
  </dependencies>
</project>

--Utilisez <dependencyManagement> pour regrouper les définitions de dépendance dans un parent

• Sous ceci, vous pouvez écrire la même chose que la normale <dependencies>
• Similaire à <pluginManagement>, la définition ici n'est qu'une déclaration, et elle est appliquée individuellement au projet.

Enfant 1 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child1</artifactId>

  <dependencies>
    <dependency>
      <groupId>commons-io</groupId>
      <artifactId>commons-io</artifactId>
    </dependency>
  </dependencies>
</project>

• Appliquer dans les projets enfants en écrivant «» et «» dans la dépendance.
• Si «» est omis, celle spécifiée par «» sera utilisée. --Il est également possible d'écraser «» indépendamment dans le projet enfant.

Enfant 2 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child2</artifactId>
</project>

• Cela ne définit aucune dépendance

Résultat de l'exécution (effectif de l'enfant 1-pom）

> mvn help:effective-pom
...
  <dependencies>
    <dependency>
      <groupId>commons-io</groupId>
      <artifactId>commons-io</artifactId>
      <version>2.6</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
...

--commons-io est appliqué dans la version définie dans le POM parent

Résultat de l'exécution (effectif de l'enfant 2)-pom）

> mvn help:effective-pom
...
  <dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
...

--La dépendance commons-io n'est pas appliquée

Agrégation de projets

--La relation parent-enfant était une forme dans laquelle l'enfant renvoyait au parent ―― En revanche, dans le cas de l'agrégation de projets, le parent fait référence à l'enfant. ――Lorsque vous agrégez des projets, vous pouvez spécifier des objectifs et des phases dans le projet parent et les exécuter.

Structure des dossiers

|-pom.xml
`-sub/
  `-pom.xml

--Projets dont le dossier supérieur est la source d'agrégation

• Il y a un projet à agréger sous le dossier enfant

Source d'agrégation pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>root</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <modules>
    <module>sub</module>
  </modules>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>Hello ${project.artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Pour agréger des projets, utilisez ` '' dans le projet à partir duquel ils sont agrégés.
• Sous <modules>, listez les projets à agréger avec <module>
• Le «» du projet à agréger doit être «pom».

Pom à agréger.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>sub</artifactId>
  <version>1.0.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>Hello ${project.artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Ecrire pom.xml pour être agrégé normalement --Comme ce POM n'hérite pas du projet de la source d'agrégation, la description de ` 'etc. est individuelle.

Résultat d'exécution (exécuté dans le projet source d'agrégation)

> mvn antrun:run
...
main:
     [echo] Hello sub
...
main:
     [echo] Hello root
...

--Lorsque vous exécutez l'objectif du plug-in dans le projet source, le même objectif est exécuté dans le projet cible. ――Lorsque vous agrégez des projets de cette manière, les commandes exécutées dans le projet source seront également exécutées dans le projet de destination. ――Il est pratique d'avoir ce mécanisme lorsque vous souhaitez construire tous les projets à la fois.

Combiner l'agrégation et les relations parent-enfant

• Les mécanismes d'agrégation et de relation parent-enfant peuvent être combinés (ou plutôt, généralement utilisés en combinaison)

Structure des dossiers

|-pom.xml
`-child/
  `-pom.xml

Pom parent.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <modules>
    <module>child</module>
  </modules>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>Hello ${project.artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--Il n'y a pas de changement particulier dans la composition du POM parent

Enfant pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child</artifactId>
</project>

--Déclarez le projet parent avec ` ''

• Cela permet aux paramètres du plug-in d'hériter des paramètres parents, éliminant ainsi le besoin de description.

Résultat de l'exécution (exécuté dans le projet parent)

> mvn antrun:run
...
main:
     [echo] Hello parent
...
main:
     [echo] Hello child
...

• La relation parent-enfant et l'agrégation peuvent être appliquées en même temps

Créer un projet Java

• Comprenez comment un projet avec un emballage jar est construit.

Objectifs par défaut exécutés dans le cycle de vie

--Si vous créez un projet qui construit Java normalement, l'empaquetage sera par défaut jar

• Par conséquent, les objectifs exécutés dans le cycle de vie default sont:
  1. resources:resources
  2. compiler:compile
  3. resources:testResources
  4. compiler:testCompile
  5. surefire:test
  6. jar:jar
  7. install:install
  8. deploy:deploy ―― Regardez ce que chaque objectif fait un par un

Collecter des ressources

• La première chose qui s'exécute est le [but de ressources] de maven-resources-plugin (https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

--Vérifiez avec la configuration minimale pom.xml

Structure des dossiers

|-pom.xml
`-src/main/
  |-java/
  | `example/
  |  `-App.java
  `-resources/
    |-hoge.txt
    `-foo/
      `-bar.txt

• Les fichiers et dossiers sont organisés de manière appropriée sous src / main / resources

Exécution de la commande

> mvn resources:resources
...
[INFO] --- maven-resources-plugin:2.6:resources (default-cli) @ hello ---
...
[INFO] BUILD SUCCESS

--resources: resources Exécuter les objectifs directement

Structure des dossiers après exécution

|-pom.xml
|-src/main/
| |-java/
| | `example/
| |  `-App.java
| `-resources/
|   |-hoge.txt
|   `-foo/
|     `-bar.txt
`-target/classes/
  |-hoge.txt
  `-foo/
    `-bar.txt

• Le contenu suivant de src / main / resources est copié dans le dossier target / classes. --maven-resources-plugin fournit le processus de copie du dossier de ressources du projet dans le dossier de sortie.
• Le dossier de ressources et le dossier de sortie sont les suivants par défaut. --Resource dossier: src / main / resources
• Dossier de sortie: cible / classes
• Le dossier de ressources est le dossier défini dans $ {project.build.resources}
• Cette valeur est définie sur $ {project.basedir} / src / main / resources dans Super POM
• Le dossier de destination de sortie est l'emplacement spécifié par le paramètre ʻoutputDirectory de l'objectif resources. --Ce paramètre est par défaut $ {project.build.outputDirectory}--Et cette valeur est définie sur$ {project.build.directory} / classes` par défaut par Super POM
• De plus, $ {project.basedir} / target est défini dans $ {project.build.directory}
• Ainsi, vous pouvez personnaliser le comportement en écrivant pom.xml, par exemple:

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <build>
    <resources>
      <resource>
        <directory>src/main/hoge</directory>
      </resource>
    </resources>
  </build>
</project>

• Changement du dossier de ressources en src / main / hoge

Structure des dossiers

|-pom.xml
`-src/main/
  |-hoge/
  | |-fizz.txt
  | `-hoge/
  |   `-fuga.txt
  |
  `-resources/
    |-buzz.txt
    `-foo/
      `-bar.txt

--Il existe deux options, src / main / resources et src / main / hoge.

Exécuter l'objectif des ressources

> mvn resources:resources
...

Résultat d'exécution

|-pom.xml
|-src/main/
| |-hoge/
| | |-fizz.txt
| | `-hoge/
| |   `-fuga.txt
| |
| `-resources/
|   |-buzz.txt
|   `-foo/
|     `-bar.txt
|
`-target/classes/
  |-fizz.txt
  `-hoge/
    `-fuga.txt

--src / main / hoge Il a changé de sorte que seul ce qui suit est copié

• En résumé, l'objectif resources: resources fonctionne par défaut comme suit:
• Copiez les fichiers et dossiers sous $ {project.basedir} / src / main / resources sous $ {project.basedir} / target / classes
• Les dossiers de ressources peuvent être définis avec <projet> <build> <resources>
• Le dossier de destination de sortie peut être défini avec <project> <build> <outputDirectory>

Compiler la source Java

• Le prochain objectif à exécuter est compile de maven-compiler-plugin. /plugins/maven-compiler-plugin/compile-mojo.html) Objectif

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

--Vérifiez avec la configuration minimale POM

Structure des dossiers

|-pom.xml
`-src/main/java
  `-example/
    `-Hello.java

--Configuration simple avec seulement Hello.java

Exécuter l'objectif de compilation

> mvn compiler:compile
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-cli) @ hello ---
...
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR]L'option source 5 n'est actuellement pas prise en charge. Veuillez utiliser 6 ou une version ultérieure.
[ERROR]Option cible 1.5 n'est actuellement pas pris en charge. 1.Veuillez utiliser 6 ou une version ultérieure.

• Echec en raison d'une erreur --Option de compilation [-source](https://docs.oracle.com/javase/jp/11/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-B4EE2436-E146- 428D-A3CB-E0DAE27BA5B7) et [-target](https://docs.oracle.com/javase/jp/11/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-89CFF-DE1-9 Le contenu de l'erreur est que la version spécifiée dans 4EA0-AB7D-B418FA2C3DE9) est trop ancienne avec «5», «1.5». --Dans JDK 11, les versions inférieures à 5 pour -source et -target sont [ne peuvent pas être spécifiées](https://docs.oracle.com/javase/jp/11/migrate/index.html# JSMIG-GUID-77874D97-46F3-4DB5-85E4-2ACB5F8D760B) --Si l'empaquetage est jar, la version par défaut de maven-compiler-plugin est [3.1](https://maven.apache.org/ref/3.6.3/maven- core / default-bindings.html # Plugin_bindings_for_jar_packaging) --Dans 3.1 de maven-compiler-plugin, la spécification de version de -source et de -target est [1.5] par défaut (https://github.com/apache/maven-compiler- plugin / blob / maven-compiler-plugin-3.1 /src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L120)
• D'ailleurs, dans la version 3.8.1 du dernier maven-compiler-plugin au moment de la confirmation, [1.6](https://github.com/apache/maven-compiler-plugin/blob/maven-compiler-plugin-3.8. 1 / src / main / java / org / apache / maven / plugin / compiler / AbstractCompilerMojo.java # L100) est la valeur par défaut --Ainsi, pour éliminer cette erreur, vous devez augmenter la version de maven-compiler-plugin ou augmenter la spécification de source et de cible. --Il est sûr de spécifier les deux pour confirmer l'opération.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

• Pour spécifier source avec maven-compiler-plugin, utilisez paramètre source. Ensemble --Bien qu'il puisse être spécifié avec <configuration>, il peut également être spécifié avec la propriété maven.compiler.source.
• Ici, le paramètre utilisant la propriété est utilisé (est-ce plus courant?)
• La même chose est vraie pour target, qui peut être définie avec la propriété maven.compiler.target.

Résultat d'exécution

> mvn compiler:compile
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-cli) @ hello ---
...
[WARNING] File encoding has not been set, using platform encoding MS932, i.e. build is platform dependent!
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
...

• J'ai pu compiler, mais j'ai reçu un avertissement
• L'avertissement est que l'encodage du fichier source dépend des valeurs par défaut de l'environnement. --Spécifiez l'encodage du fichier source dans paramètre d'encodage. --Comme décrit dans la description, il utilise par défaut $ {project.build.sourceEncoding} --Cependant, cette valeur n'est pas définie dans Super POM, il en résulte donc un environnement par défaut (tel que MS932 pour Windows).
• Alors, définissons également l'encodage

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

--De la description $ {project.build.sourceEncoding}, vous pouvez penser que vous devriez décrire l'élément <sourceEncoding> sous <project> <build>, mais en réalité, vous déclarez la propriété ( Qui sait </ del>) Au fait, il est possible de le définir avec la propriété ʻencoding, mais si vous le recherchez sur le net, la méthode de project.build.sourceEncoding` sera interceptée. ――S'il s'agit d'un «encodage», il peut être appliqué à des encodages autres que la source Java, ou existe-t-il une telle chose? (adapté)

Résultat d'exécution

> mvn compiler:compile
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-cli) @ hello ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

• Compilé avec succès sans avertissement

Résultat de sortie

|-pom.xml
|-src/main/java/
| :
`-target/
  |-classes/
  : `-example/
      `-Hello.class

• Le résultat de la compilation est affiché sous target / classes
• Le paramètre de destination de sortie n'est pas décrit dans le document objectif de compilation. --Il s'agit de la classe d'implémentation de l'objectif compile [outputDirectory](https://github.com/apache/maven-compiler-plugin/blob/maven-compiler-plugin-3.8.1/src/main/java /org/apache/maven/plugin/compiler/CompilerMojo.java#L76) Déclaré dans le champ
• La valeur par défaut est $ {project.build.outputDirectory} --Depuis que readonly = true est défini, ce champ ne peut pas être défini directement de l'extérieur.
• Le dossier source est par défaut src / main / java
• De plus, il n'y a pas de description dans le document --En termes de mise en œuvre, [compileSourceRoots](https://github.com/apache/maven-compiler-plugin/blob/maven-compiler-plugin-3.8.1/src/main/java/org/apache/maven/plugin /compiler/CompilerMojo.java#L70) déclaré dans le champ
• En regardant defaultValue, vous pouvez voir que$ {project.compileSourceRoots} est défini. --Mais quand j'essaye de référencer cette propriété appeléeproject.compileSourceRoots sur pom.xml, je ne vois pas la valeur. --compileSourceRoots` est [MavenProject](https://github.com/apache/maven/blob/maven-3.6.3/maven-core/src/main/java/org/apache/maven/project/MavenProject.java # L131) Déclaré comme champ de classe --Ce champ est DefaultProjectBuilder La valeur est définie par # L691)
• A partir de cette implémentation, vous pouvez voir que project.build.sourceDirectory est défini sur compileSourceRoots. --Et $ {project.basedir} / src / main / java est défini dans project.build.sourceDirectory par Super POM. ――Si vous regardez ce mécanisme, vous pouvez vous attendre à ne pas pouvoir définir plusieurs dossiers source.
• Si vous souhaitez définir plusieurs dossiers sources, vous devez installer un plugin appelé build-helper-maven-plugin.

• En résumé, compiler: compile fait ce qui suit: --Compilez le code source Java sous $ {project.basedir} / src / main / java et sortez-le dans $ {project.basedir} / target / classes Les options -source, -target de --javac peuvent être spécifiées avec les propriétés maven.compiler.source, maven.compiler.target
• L'encodage peut être spécifié avec la propriété project.build.sourceEncoding.
• Le dossier source peut être spécifié avec <project> <build> <sourceDirectory>
• Si vous souhaitez spécifier plusieurs dossiers, vous avez besoin de build-helper-maven-plugin
• Le dossier de destination de sortie est <project> <build> <outputDirectory>

Collecte et compilation de ressources pour les tests

• La prochaine chose à exécuter est resources: testResources, qui collecte les ressources de test. Devenez compiler: testCompile pour compiler le code source à des fins de test
• Le fonctionnement de base de chacun est le même que resources: resources, compiler: compile, donc seulement approximativement

Structure des dossiers

|-pom.xml
`-src/test/
  |-java/
  | `-example/
  |   `-HelloTest.java
  |
  `-resources/
    |-foo/
    | `-bar.txt
    `-fizz.txt

• Le code source du test sous src / test / java, Placez les fichiers de ressources de test sous src / test / resources

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

--pom.xml est le même que pour compiler: compile

Courir

> mvn resources:testResources compiler:testCompile
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-cli) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-cli) @ hello ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

Résultat d'exécution

|-pom.xml
|-src/test/
| :
`-target/
  `-test-classes/
    |-fizz.txt
    |-foo/
    | `-bar.txt
    `-example/
      `-HelloTest.class

• Les résultats sont affichés sous target / test-classes

――Une fois organisé, l'opération est la suivante.

• Le but de testResources est de copier les fichiers et dossiers sous $ {project.basedir} / src / test / resources dans $ {project.basedir} / target / test-classes.
• Les dossiers de ressources peuvent être spécifiés avec <project> <build> <testResources>
• Le but testCompile compile les fichiers source Java sous $ {project.basedir} / src / test / java et les renvoie dans $ {project.basedir} / target / test-classes.
• Le dossier source peut être spécifié avec <projet> <build> <testSourceDirectory>

Lancer le test

• Ensuite, pour exécuter le code de test compilé, [objectif de test](https: //) de maven-surefire-plugin maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html) est exécuté.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.6.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.22.2</version>
      </plugin>
    </plugins>
  </build>
</project>

• Les modifications suivantes ont été apportées pour faire fonctionner JUnit5. --Ajout de junit-jupiter aux dépendances
• Spécifiez 2.22.2 pour la version de maven-surefire-plugin --2.22.0 ou supérieur doit être spécifié pour utiliser JUnit5

Structure des dossiers

|-pom.xml
`-src/
  |-main/java/
  | `-example/
  |   `-Hello.java
  `-test/java/
    `-example/
      `-HelloTest.java

--Placez la classe cible de test (Hello.java) et la classe de test ( HelloTest.java)

Courir

> mvn test
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @ hello ---
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running example.HelloTest
...
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 s - in example.HelloTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

> dir /b target\surefire-reports
example.HelloTest.txt
TEST-example.HelloTest.xml

--L'objectif surefire: test est lié à la phase test, il est donc exécuté avec la phase test spécifiée. --Il est possible d'exécuter surefire: test seul, mais dans ce cas, la source doit être compilée séparément.

• La classe de test à exécuter est spécifiée dans inclut le paramètre, et les classes suivantes sont exécutées par défaut. Est ciblé
  • **/Test*.java
  • **/*Test.java
  • **/*Tests.java
  • **/*TestCase.java
• Les résultats des tests sont imprimés au format texte et xml sous target / surefire-reports
• Ceci est spécifié dans l'objectif surefire: test paramètre reportsDirectory (la valeur par défaut est $ {project.build.directory} / surefire-reports)

Passer le test

--Après la phase test, la phase package est exécutée, ce qui fige le résultat de la compilation du projet dans un fichier jar.

• Autrement dit, la phase test doit se terminer avec succès pour générer un fichier jar.
• Si le test échoue dans la phase test, la phase package ne fonctionnera pas
• Il devrait être que le code qui n'a pas réussi le test ne soit pas utilisable même s'il est emballé dans un bocal, mais malheureusement, il y a des projets où le code de test n'est pas maintenu et le test échoue.
• Dans de tels cas, il est courant d'ignorer l'exécution de la phase «test» et d'exécuter la phase «package» (ce qui ne devrait pas être le cas).

Résultat d'exécution

> mvn -DskipTests package
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello ---
[INFO] Tests are skipped.
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello ---
...

--surefire: test Le but a un paramètre appelé skipTests. --Si ce paramètre est défini, l'exécution du test sera ignorée.

• Pour résumer, la phase test effectue les opérations suivantes:
• Le code de test est exécuté par maven-surefire-plugin
• Pour utiliser JUnit 5, la version de maven-surefire-plugin doit être 2.22.0 ou supérieure.
• La classe de test à exécuter est spécifiée dans inclut le paramètre.
• Les résultats des tests sont imprimés sous target / surefire-reports (paramètre reportsDirectory" )
• L'exécution du test peut être ignorée en définissant le paramètre skipTests --Cependant, son utilisation doit être limitée au minimum nécessaire
• Le test n'est pas maintenu et vous avez besoin d'un pot pour le moment (la bonne réponse est de le réparer pour que le test réussisse) --Le test réussit, mais il prend beaucoup de temps à s'exécuter, il ne peut donc pas être exécuté à chaque fois. - etc

Durcir en pot

--Le processus de solidification du résultat de la compilation dans un fichier jar est le [but du jar](https: //maven.apache) de maven-jar-plugin. .org / plugins / maven-jar-plugin / jar-mojo.html)

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

• Les paramètres minimum requis pour la compilation

Structure des dossiers

|-pom.xml
`-src/
  |-test/
  | :
  `-main/
    |-java/
    | `-example/
    |   `-Hello.java
    `-resources/
      `-hoge.txt

Phase d'exécution du package

> mvn package
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @ hello ---
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

--L'objectif jar: jar est lié à la phase package, vous exécutez donc la phase package.

Résultat d'exécution

|-pom.xml
|-src/
| :
`-target/
  |-hello-1.0.0.jar
  :

--hello-1.0.0.jar est affiché directement sous le dossier target.

• La destination de sortie du fichier jar est définie par le paramètre outputDirectory de l'objectif jar.
• La valeur par défaut de ce paramètre est $ {project.build.directory} ($ {project.basedir} / target)
• De plus, le nom du fichier jar est finalName dans l'implémentation de l'objectif jar. /org/apache/maven/plugins/jar/AbstractJarMojo.java#L80) déclaré dans le champ --Ce champ est readonly = true, il ne peut donc pas être modifié directement de l'extérieur. --La valeur de ce champ est définie sur $ {project.build.finalName} --Cette valeur est définie par Super POM sur $ {project.artifactId} - $ {project.version} par défaut. --Par conséquent, si vous souhaitez renommer le jar, vous pouvez définir <project> <build> <finalName>
• Lorsque vous décompressez ce fichier, le contenu est le suivant

text:hello-1.0.0.Contenu du pot

|-hoge.txt
|-example/
| `-Hello.class
`-META-INF/
  |-MANIFEST.MF
  `-maven/example/hello/
    |-pom.properties
    `-pom.xml

--hoge.txt et Hello.class sont emballés avec la sortie sous target / classes par resources: resources et compiler: compile, respectivement.

• Le contenu du dossier compressé dans un fichier jar est défini par le paramètre classesDirectory de l'objectif du fichier jar. A été
• La valeur par défaut de ce paramètre est $ {project.build.outputDirectory} ($ {project.basedir} / target / classes) --Pom.xml est affiché sous META-INF, mais le contenu est le même que pom.xml de ce projet. --MANIFEST.MF et pom.properties ont respectivement le contenu suivant.

MANIFEST.MF

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven 3.6.3
Built-By: xxxxx
Build-Jdk: 11.0.6

pom.properties

#Generated by Maven
#Sun Mar 29 21:59:48 JST 2020
groupId=example
artifactId=hello
version=1.0.0

• Celles-ci sont définies dans le paramètre archive du but jar.
• Les détails des paramètres ʻarchive` peuvent être trouvés dans Apache Maven Archiver - Reference.
• Ces fichiers sont générés avec les paramètres activés par défaut

• En résumé, l'objectif jar fonctionne comme ceci:
• nom de fichier
  • ${project.artifactId}-${project.version} --Spécifiez avec <projet> <build> <finalName> pour changer
• Emplacement de sortie
  • ${project.basedir}/target --Spécifiez avec <projet> <build> <directory> pour changer
• Cible d'emballage
  • ${project.basedir}/target/classes --Si vous souhaitez le modifier, spécifiez-le avec le paramètre <project> <build> <outputDirectory> ou classesDirectory de l'objectif jar.
• De plus, le paramètre ʻarchivepeut être utilisé pour définir les informations ajoutées sousMANIFEST.MF et META-INF`.

Installer dans le référentiel local

--ʻInstall` Le [objectif d'installation](https: // maven.) De maven-install-plugin associé à la phase. apache.org/plugins/maven-install-plugin/install-mojo.html) offre la possibilité d'installer des artefacts de projet dans un référentiel local.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
  ...
</project>

Lancer l'installation

> mvn install
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

--ʻInstall: install L'objectif est lié à la phase ʻinstall, donc vous exécutez la phase ʻinstall` (déroutant) --Lorsque l'exécution est terminée, vérifiez dans le référentiel local

• L'emplacement du référentiel local est % USERPROFILE% \ .m2 \ repository sous Windows ( $ HOME / .m2 / repository sous Linux OS) --Si vous avez spécifié un emplacement différent dans settings.xml, cela

Dépôt local

Dépôt local/
 |-example/
 : `-hello/
     |-1.0.0/
     : |-hello-1.0.0.jar
       :

• Le fichier jar est stocké dans le référentiel local
• Le fichier jar enregistré est probablement le fichier jar généré dans la phase package --ʻInstall: installLe document d'objectif indiquait "l'artefact principal du projet", mais je n'ai pas pu trouver une description claire de ce qui serait "l'artefact principal du projet". --En termes de mise en œuvre, [MavenProject getArtifact ()](https://github.com/apache/maven/blob/maven-3.6.3/maven-core/src/main/java/org/apache/maven/project [Artifact getFile ()](https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/) qui peut être obtenu avec /MavenProject.java#L215) Je pourrais lire jusqu'au point où le fichier qui peut être obtenu par apache / maven / artifact / Artifact.java # L85) semble être installé, mais je n'ai pas pu trouver l'endroit où cet objetFile` est placé.
• Les artefacts installés dans le référentiel local seront visibles dans un autre projet local

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>foo</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>example</groupId>
      <artifactId>hello</artifactId>
      <version>1.0.0</version>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

--Déclarer les dépendances sur hello-1.0.0.jar avec <dependencies>

Foo.java

package example;

public class Foo {
    public static void main(String... args) {
        new Hello().hello();
    }
}

• J'écris une implémentation qui utilise la classe Hello

Compilez le projet

> mvn compile
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ foo ---
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ foo ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

--Compilé (la classe Hello a été résolue)

• En résumé, l'objectif ʻinstall` fonctionne comme suit:
• Installez probablement les artefacts (tels que les fichiers jar) générés dans la phase package dans votre référentiel local
• Les artefacts installés seront visibles en tant que dépendances d'autres projets locaux

Déployer

• La dernière exécution est la phase de déploiement --Dans la phase deploy, l 'objectif de déploiement de maven-deploy-plugin plugins / maven-deploy-plugin / deploy-mojo.html) est exécuté
• Objectif de déploiement: déploie les artefacts du projet dans un référentiel distant ―― Je pense qu'il y a peu d'opportunités de l'utiliser même s'il est difficile de créer l'environnement. </ Del> La vérification est omise.

Construire un projet Web

Voyez comment votre projet se construit si vous définissez --packaging sur war

• Cependant, le plug-in exécuté dans la phase default est presque le même que dans le cas de jar.
• La différence avec jar est que le but exécuté dans la phase package est war war goal

Structure des dossiers

|-pom.xml
`-src/main/
  |-java/
  | `-example/webapp/
  |   `-HelloServlet.java
  `-webapp/
    `-WEB-INF/
      `-hello.jsp

--Créez un dossier appelé src / main / webapp, et créez des dossiers sous celui-ci tels que WEB-INF à inclure dans war.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>webapp</artifactId>
  <version>1.0.0</version>
  <packaging>war</packaging>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>javax.servlet-api</artifactId>
      <version>4.0.1</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.10</version>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>3.2.3</version>
      </plugin>
    </plugins>
  </build>
</project>

--war est spécifié pour<packaging> --Les deux suivants sont spécifiés comme dépendances - Servlet API - Apache Commons Lang3

Construire

> mvn package
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ webapp ---
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ webapp ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ webapp ---
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ webapp ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ webapp ---
...
[INFO] --- maven-war-plugin:3.2.3:war (default-war) @ webapp ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

• Comme dans le cas de «jar», le but du plug-in est exécuté à chaque phase, et enfin «war: war» est exécuté.

Résultat de sortie

|-pom.xml
|-src/
| :
`-target/
  `-webapp-1.0.0.war

• Le fichier war est généré directement sous target
• L'emplacement de sortie est spécifié dans le [paramètre outputDirectory] de l'objectif war (https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#outputDirectory) et par défaut à$ C'est {project.build.directory} --Le nom du fichier war est [warName](https://github.com/apache/maven-war-plugin/blob/maven-war-plugin-3.2.3/src/main/java/org/apache/ Il est spécifié par un paramètre en lecture seule appelé maven / plugins / war / WarMojo.java # L71) et vaut par défaut $ {project.build.finalName}.
• Le contenu de webapp-1.0.0.war est le suivant

text:webapp-1.0.0.Le contenu de la guerre

webapp-1.0.0.war/
|-WEB-INF/
| |-hello.jsp
| |-classes/
| | `-example/webapp/
| |   `-HelloServlet.class
| `-lib/
|   `-commons-lang3-3.10.jar
`-META-INF/
  |-MANIFEST.MF
  `-maven/example/webapp/
    |-pom.properties
    `-pom.xml

• Vous pouvez voir que le résultat de la compilation de src / main / java et le contenu sous src / main / webapp sont contenus dans le fichier war.
• Placez les fichiers autres que les fichiers de classe et les fichiers jars de bibliothèque que vous avez mis en guerre dans le dossier src / main / webapp.
• Ceci est spécifié dans le [paramètre warSourceDirectory] du but war (https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#warSourceDirectory) et par défaut à $ { basedir} / src / main / webapp
• De plus, le fichier jar Apache Commons Lang3 spécifié comme dépendance est également stocké sous WEB-INF / lib.
• Le fichier jar de l'API Servlet n'est pas stocké
• Ceci est dû au fait que la portée de la dépendance vis-à-vis de l'API Servlet a été spécifiée dans «fourni».
• Une explication détaillée de la portée sera décrite plus tard.

• En résumé, si le packaging est war, le projet sera construit comme suit:
• Fondamentalement construit comme jar
• Cependant, le fait que le but war: war est exécuté uniquement dans la phase package est différent du cas de jar. --Dans le but war: war, le résultat de la compilation du projet est sorti dans un fichier war. --En plus du fichier de classe, de la ressource et de la bibliothèque dépendante, le fichier placé sous src / main / webapp est également stocké dans la guerre tel quel.

Exécutez une application Java

Hello.java

package example;

import java.util.Arrays;

public class Hello {
    public static void main(String... args) {
        System.out.println("Hello World! args=" + Arrays.toString(args));
    }
}

--Hello World, implémentation qui génère des arguments de ligne de commande

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>1.6.0</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <mainClass>example.Hello</mainClass>
              <arguments>
                <argument>one</argument>
                <argument>two</argument>
                <argument>three</argument>
              </arguments>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

• Un plugin appelé exec-maven-plugin a été ajouté.

Courir

> mvn compile exec:java
...
[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ hello ---
Hello World! args=[one, two, three]
...

--Hello.java a été exécuté --Si vous utilisez le but java de ʻexec-maven-plugin, vous pouvez mettre le résultat de la construction du projet dans le chemin de classe. Peut exécuter des programmes Java --ʻExec-maven-plugin a également un objectif d'exécution qui vous permet d'exécuter des commandes arbitraires. Omis ici

• mainClass Vous pouvez exécuter des programmes Java en spécifiant la classe Main avec le paramètre.
• arguments Vous pouvez passer des arguments de ligne de commande avec des paramètres.
• Vous pouvez également passer un argument avec le paramètre commandlineArgs, mais ceci est à utiliser lors de l'exécution à partir de la ligne de commande décrite plus tard (probablement).

Exécuter à partir de la ligne de commande

• Pour le premier exemple, il est nécessaire de décrire à l'avance toutes les configurations d'exécution dans pom.xml.
• Dans certains cas, vous souhaiterez peut-être l'exécuter tout en modifiant divers arguments sur la ligne de commande.
• Dans ce cas, il est plus facile de spécifier les paramètres de l'objectif via les propriétés système.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>1.6.0</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <mainClass>example.Hello</mainClass>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

--Il est difficile de spécifier la classe Main à partir de la ligne de commande, donc je pense que seul cela peut être décrit à l'avance dans pom.xml.

Résultat d'exécution

> mvn compile exec:java -Dexec.args="ONE TWO THREE"
...
Hello World! args=[ONE, TWO, THREE]

• commandlineArgs Vous pouvez utiliser le paramètre pour spécifier l'argument sous forme de chaîne séparée par des espaces. --Lors de la spécification dans les propriétés système, spécifiez dans ʻexec.args`

Dépendances

Périmètre de dépendance

• Vous pouvez définir une dépendance appelée ** Scope ** --Scope représente la plage dans laquelle la dépendance est utilisée.
• Par exemple, la dépendance spécifiée dans la portée compile indique qu'elle est toujours utilisée à partir du moment où le code source est compilé jusqu'au moment où l'application est exécutée.
• De plus, la dépendance avec la portée test indique qu'elle ne doit être utilisée que lors de la compilation du code de test ( src / test / java) et de l'exécution du test. --Il existe 6 types de portées comme suit.
  • compile
  • provided
  • runtime
  • test
  • system
  • import

compiler la portée

pom.xml

<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-lang3</artifactId>
  <version>3.10</version>
</dependency>

• Si aucune portée n'est spécifiée, la portée compile est adoptée par défaut (elle peut être spécifiée).
• La portée compile indique que la dépendance est toujours requise de la compilation à l'exécution.

portée fournie

pom.xml

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
  <version>4.0.1</version>
  <scope>provided</scope>
</dependency>

• La portée provided indique que la dépendance est fournie par l'environnement d'exécution.
• À utiliser lorsque les conditions suivantes sont remplies
• Requis pour la compilation et les tests
• Cependant, l'environnement d'exécution fournit le fichier jar au moment de l'exécution, l'application n'a donc pas besoin de le conserver séparément.
• L'exemple le plus courant est l'API Servlet.
• L'API Servlet utilise celle fournie par le serveur d'applications qui déploie la guerre, de sorte que l'application n'a pas besoin d'avoir des dépendances individuelles au moment de l'exécution.
• Pour la même raison, spécifiez les autres API (EJB, JAX-RS, etc ...) fournies par Java EE (Jakarta EE) avec provided.
• Lorsqu'une guerre est générée avec maven-war-plugin, les dépendances spécifiées dans provided ne sont pas placées sous WEB-INF / lib.

portée d'exécution

pom.xml

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.2.12</version>
    <scope>runtime</scope>
</dependency>

• La portée runtime est l'opposé de provided et est utilisée avec des dépendances qui ne sont pas nécessaires au moment de la compilation mais qui sont nécessaires au moment de l'exécution.
• Un exemple typique est le pilote JDBC. --Lors de l'écriture d'un programme à l'aide du pilote JDBC, l'implémentation fournit java.sql.Connection Fourni par l'API standard. Vous n'avez qu'à vous fier à des classes telles que sql / java / sql / Connection.html)
• Fondamentalement, cela ne dépend pas directement des classes concrètes fournies par chaque produit de base de données. ――Mais, bien sûr, vous avez besoin d'une entité au moment de l'exécution
• Ainsi, cela s'applique au cas où il n'est pas nécessaire au moment de la compilation mais est nécessaire au moment de l'exécution.

portée de test

pom.xml

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.6.1</version>
    <scope>test</scope>
</dependency>

• La portéetest est utilisée pour les dépendances qui ne sont utilisées que lors de la compilation et de l'exécution de la source de test.
• Ne peut pas être utilisé lors de la compilation ou de l'exécution du code source principal
• Utiliser avec des dépendances qui ne sont nécessaires que pour les tests, telles que JUnit

portée du système

pom.xml

<dependency>
  <groupId>javax.sql</groupId>
  <artifactId>jdbc-stdext</artifactId>
  <version>2.0</version>
  <scope>system</scope>
  <systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>

• La portée system indique que la dépendance est fournie par le système (JRE ou JDK de l'environnement d'exécution).
• Cette portée semble être préparée dans le but d'utiliser des bibliothèques d'extension qui ne sont pas dans le référentiel et sont stockées en interne par le JRE et le JDK. --Si vous spécifiez la portée system, vous devez spécifier le chemin du fichier jar cible avec <systemPath>.
• Vous pouvez également avoir une bibliothèque dans votre projet qui n'existe pas dans le référentiel et l'utiliser pour la référencer. ―― À l'origine, c'est une approche simple pour préparer un référentiel privé et le gérer là-bas.
• Pour le moment, l'utilisation de cette étendue est obsolète.
  • System Dependencies

portée d'importation

Structure des dossiers

|-foo/
| `-pom.xml
`-bar/
  `-pom.xml

--Il y a deux projets, toto et bar

pom.xml(foo)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>foo</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <dependencyManagement>
    <dependencies>
      <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-lang3</artifactId>
          <version>3.10</version>
      </dependency>
      <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-text</artifactId>
          <version>1.8</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

• Le projet foo définit l'empaquetage sur pom et déclare uniquement <dependencyManagement>
• Les deux suivants sont déclarés comme cibles dépendantes.
  • org.apache.commons:commons-lang3:3.10
  • org.apache.commons:commons-text:1.8

pom.xml(bar)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>bar</artifactId>
  <version>1.0.0</version>

  <dependencyManagement>
    <dependencies>
      <dependency>
          <groupId>example</groupId>
          <artifactId>foo</artifactId>
          <version>1.0.0</version>
          <type>pom</type>
          <scope>import</scope>
      </dependency>
      <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-lang3</artifactId>
          <version>3.9</version>
      </dependency>
      <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-csv</artifactId>
          <version>1.8</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

--Dans le projet de barre, dans <dependencyManagement>, le projet foo précédent est spécifié dans la portée ʻimport. --ʻImport La portée ne peut être spécifiée que dans <dependencyManagement> --Si vous spécifiez la portée ʻimport, vous devez également spécifier le pom </ type>. --En outre, les deux suivants sont déclarés comme d'autres objets dépendants. - org.apache.commons:commons-lang3:3.9 -org.apache.commons:commons-csv:1.8`

• Dans cet état, vérifiez ʻeffective-pom` du projet de barre.

effective-Confirmation de pom(bar)

> cd bar

> mvn help:effective-pom
...
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.9</version>
      </dependency>
      <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-csv</artifactId>
        <version>1.8</version>
      </dependency>
      <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-text</artifactId>
        <version>1.8</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

• Les déclarations de dépendances sur le projet foo ont disparu et à la place les dépendances déclarées dans <dependencyManagement> '' du projet foo ont été ajoutées. --Cependant, si les artefacts sont dupliqués, la version du projet de barre est adoptée (commons-lang3`).
• Comme vous pouvez le voir, ʻimporta une portée spéciale pour importer (importer)` d'autres projets pom.

BOM --Il existe une méthode appelée ** BOM (nomenclature) ** qui utilise la portée ʻimport` comme méthode de gestion des versions de dépendance pour les multi-projets. --Pour la nomenclature, préparez d'abord un projet de nomenclature avec pom.xml.

• Le pom.xml du projet BOM déclare «», qui définit les dépendances utilisées par chaque projet. --Pour chaque projet, chargez ce projet de nomenclature dans le périmètre ʻimport`
• Les versions de dépendance sont déclarées dans les projets de nomenclature, donc chaque projet n'a besoin que de déclarer groupId, ʻartifactId dans `
• Cela permet au projet de nomenclature de gérer de manière centralisée les versions de dépendance utilisées par tous les projets.
• En passant, la nomenclature de Spring Boot est [ici](https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/2.2.6.RELEASE/spring-boot-dependencies-2.2. 6.RELEASE.pom)
• En chargeant cette nomenclature, vous pouvez faire correspondre la version de la bibliothèque que vous utilisez à celle prise en charge par Spring Boot.

• Afin de donner une vue d'ensemble de la portée de chaque portée, j'ai fait un tableau de la relation entre la portée et le but (exclu car «import» est spécial).

• Le «○» indique que l'objectif fait référence à et utilise la dépendance de la portée correspondante.
• Pour war: war, cela signifie s'il sera emballé dans le fichier war généré. --Autre que cela, cela signifie s'il est défini ou non dans le chemin de classe.

Vérifiez les dépendances dans l'arborescence

• Vous pouvez vérifier la dépendance du projet en l'affichant dans un graphique en arborescence.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>5.2.5.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-jdbc</artifactId>
      <version>5.2.5.RELEASE</version>
    </dependency>
  </dependencies>
</project>

--Déclarer le Web Spring Framework et jdbc en tant que dépendances «Cependant, les bibliothèques dont dépend le projet ne sont pas limitées à cela, et en fait, elles dépendent également des bibliothèques dont dépendent« spring-web »et« spring-jdbc ».

• Vous ne pouvez pas dire simplement en regardant pom.xml de combien de bibliothèques dépend votre projet.
• objectif d'arborescence de maven-dependency-plugin Si vous exécutez plugin / tree-mojo.html), vous pouvez voir toutes les dépendances incluant cette dépendance transitionnelle dans le graphique de l'arborescence.

Résultat d'exécution

> mvn dependency:tree
...
[INFO] +- org.springframework:spring-web:jar:5.2.5.RELEASE:compile
[INFO] |  +- org.springframework:spring-beans:jar:5.2.5.RELEASE:compile
[INFO] |  \- org.springframework:spring-core:jar:5.2.5.RELEASE:compile
[INFO] |     \- org.springframework:spring-jcl:jar:5.2.5.RELEASE:compile
[INFO] \- org.springframework:spring-jdbc:jar:5.2.5.RELEASE:compile
[INFO]    \- org.springframework:spring-tx:jar:5.2.5.RELEASE:compile
...

• On peut voir que "spring-web" dépend en outre de "spring-beans", "spring-core" et "spring-core" dépend de "spring-jcl".
• Et vous pouvez voir que spring-jdbc dépend de spring-tx
• Au fait, spring-jdbc dépend également de spring-beans et de spring-core, mais l'affichage est omis car il chevauche le côté spring-web. --Par défaut, les dépendances de toutes les étendues sont affichées, mais vous pouvez également affiner par paramètre de portée. ça peut

Collecter les pots de dépendance

• Dans de rares cas, vous souhaitez obtenir tous les fichiers jar réels dont dépend votre projet.
• Ceci peut être réalisé avec le but des dépendances de copie de maven-dependency-plugin. -Essayez d'exécuter avec les mêmes paramètres que pom.xml dans ↑

Résultat d'exécution

> mvn dependency:copy-dependencies
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

> dir /b target\dependency
spring-beans-5.2.5.RELEASE.jar
spring-core-5.2.5.RELEASE.jar
spring-jcl-5.2.5.RELEASE.jar
spring-jdbc-5.2.5.RELEASE.jar
spring-tx-5.2.5.RELEASE.jar
spring-web-5.2.5.RELEASE.jar

• Tous les fichiers JAR dépendants sont affichés dans le dossier target / dependency --Par défaut, les fichiers JAR de toutes les étendues sont ciblés, mais limités par paramètre includeScope etc. être capable de

Profil

• Fondamentalement, il est bon de créer le projet de sorte que le même résultat soit généré avec les mêmes paramètres dans chaque environnement. ――La compilation réussit dans un environnement, mais une erreur se produit dans un autre environnement, ce qui est gênant. Cependant, il semble qu'il soit rare que des paramètres de construction dépendants de l'environnement soient requis pendant le développement réel (bien que je ne sache pas).
• Si vous souhaitez modifier le contenu de pom.xml en fonction de l'environnement de construction (activer un plug-in spécifique ou modifier la valeur du paramètre), vous pouvez utiliser un mécanisme appelé ** Profile **.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <profiles>
    <profile>
      <id>foo</id>

      <properties>
        <message>foo profile!!</message>
      </properties>

      <dependencies>
        <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-lang3</artifactId>
          <version>3.10</version>
        </dependency>
      </dependencies>

      <build>
        <directory>${project.basedir}/build</directory>
      </build>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>message = ${message}</echo>
            <echo>project.build.directory = ${project.build.directory}</echo>
            <echo>dependency[0] = ${project.dependencies[0].artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--<profiles> <profile>déclare un profil appelé foo --Dans le profil foo, les propriétés, les dépendances et les paramètres project.build.directory sont définis.

• J'utilise maven-antrun-plugin pour afficher ces valeurs.

Résultat d'exécution

> mvn antrun:run
...
     [echo] message = ${message}
     [echo] project.build.directory = F:\tmp\maven\hello\target
     [echo] dependency[0] = ${project.dependencies[0].artifactId}
...

> mvn -P foo antrun:run
...
     [echo] message = foo profile!!
     [echo] project.build.directory = F:\tmp\maven\hello\build
     [echo] dependency[0] = commons-lang3

• Lorsqu'il est exécuté normalement, le contenu défini dans le profil foo n'est pas reflété.
• D'un autre côté, si vous spécifiez -P foo et que vous l'exécutez, vous pouvez voir que le contenu défini dans le profil foo est reflété.
• De cette manière, l'utilisation d'un profil vous permet de définir des paramètres qui s'appliquent uniquement lorsque vous utilisez ce profil.
• La définition du profil est décrite par <profile> '' --Définissez un nom pour identifier de manière unique le profil avec '' --Autre que cela, vous pouvez essentiellement décrire les éléments qui peuvent être décrits dans pom.xml (<dependencies>, <build>, etc.) tels qu'ils sont. --Pour spécifier le profil, spécifiez «-P» suivi de «» du profil sur la ligne de commande.

Spécifiez plusieurs profils et exécutez

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>foo</id>
      <properties>
        <foo>FOO</foo>
        <message>foo profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>bar</id>
      <properties>
        <bar>BAR</bar>
        <message>bar profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>foo = ${foo}</echo>
            <echo>bar = ${bar}</echo>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--Déclarer deux profils, foo et bar --message est déclaré dans les deux profils pour le dupliquer

Résultat d'exécution

> mvn -P bar,foo antrun:run
...
     [echo] foo = FOO
     [echo] bar = BAR
     [echo] message = bar profile!!

--Lors de la spécification de plusieurs profils, listez les «id» séparés par des virgules.

• Les éléments en double semblent être adoptés plus tard sur pom.xml (il ne semble pas être dans l'ordre spécifié dans le profil)

Activer le profil par défaut

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>foo</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <message>foo profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>bar</id>
      <properties>
        <message>bar profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--Le profil foo est défini sur <activeByDefault> true </ activeByDefault>

Résultat d'exécution

> mvn antrun:run
...
     [echo] message = foo profile!!
...

> mvn -P bar antrun:run
...
     [echo] message = bar profile!!

• La propriété foo est activée par défaut --Si vous définissez <activation> <activeByDefault> sur true, le profil sera activé par défaut. --Si un profil différent est spécifié avec -P, le profil avec <activeByDefault> ʻis true` sera invalide.

Activer le profil uniquement lorsque les conditions sont remplies

Activer les propriétés système si elles sont déclarées

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>foo</id>
      <activation>
        <property>
          <name>foo</name>
        </property>
      </activation>
      <properties>
        <message>foo profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--Déclarer <propriété> dans <activation>

Résultat d'exécution

> mvn antrun:run
...
     [echo] message = ${message}
...

> mvn -Dfoo antrun:run
...
     [echo] message = foo profile!!

--Le profil n'est pas spécifié par -P, mais le profil foo est activé en déclarant la propriété système avec -Dfoo. --Dans <activation>, vous pouvez définir les conditions pour activer le profil. --<propriété>peut être spécifié à la condition qu'une propriété système soit déclarée ou qu'une valeur spécifique soit définie.

• Ici, seul <nom> foo </ nom> est défini, donc si la propriété système foo est définie, le profil sera valide quelle que soit la valeur. --Si la valeur est également une condition, déclarez <valeur> comme suit:

Lorsque la valeur de la propriété système est également incluse dans la condition

        <property>
          <name>foo</name>
          <value>enable</value>
        </property>

Résultat d'exécution

> mvn -Dfoo antrun:run
...
     [echo] message = ${message}
...

> mvn mvn -Dfoo=enable antrun:run
...
     [echo] message = foo profile!!

• Le profil foo est activé uniquement lorsque la valeur de la propriété système foo est ʻenable`.

Conditionné à la version JDK

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>jdk11</id>
      <activation>
        <jdk>11</jdk>
      </activation>
      <properties>
        <message>jdk11 profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>jdk14</id>
      <activation>
        <jdk>14</jdk>
      </activation>
      <properties>
        <message>jdk14 profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Vous utilisez l'élément <jdk> dans <activation>

Résultat d'exécution

> java --version
openjdk 11.0.6 2020-01-14
...

> mvn antrun:run
...
     [echo] message = jdk11 profile!!
...

> java --version
openjdk 14 2020-03-17
...

> mvn antrun:run
...
     [echo] message = jdk14 profile!!

• Le profil a été changé en fonction de la version de JDK lors de l'exécution.
• Vous pouvez utiliser <jdk> pour faire de la version Java au moment de l'exécution une condition pour l'application de profil. --La condition décrite dans <jdk> correspond au préfixe et est comparée à la version Java.
• Si vous spécifiez «11», il correspond également à «11.0.6» car il s'agit d'une correspondance de préfixe.
• De plus, vous pouvez écrire une spécification de plage telle que (, 11] (dans ce cas, elle correspond à 11 ou versions inférieures)
• Voir Apache Maven Enforcer Built-In Rules - Version Range Specification pour savoir comment écrire des spécifications de plage.
• La valeur obtenue par la propriété système java.version est utilisée pour la version Java à comparer.
• La mise en œuvre est probablement [ceci](https://github.com/apache/maven/blob/maven-3.6.3/maven-model-builder/src/main/java/org/apache/maven/model/profile/ activation / JdkVersionProfileActivator.java # L66) --La condition peut être refusée en la préfixant avec !, Comme <jdk>! 11 </ jdk>.

Conditionner le système d'exploitation

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>Windows</id>
      <activation>
        <os>
          <name>Windows 10</name>
        </os>
      </activation>
      <properties>
        <message>Windows profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>Linux</id>
      <activation>
        <os>
          <name>Linux</name>
        </os>
      </activation>
      <properties>
        <message>Linux profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--<activation>est réglé sur<os>

Résultat d'exécution(Windows)

> mvn antrun:run
...
     [echo] message = Windows profile!!

Résultat d'exécution(Linux)

> mvn antrun:run
...
     [echo] message = Linux profile!!

• Le profil appliqué est commuté en fonction du système d'exploitation lors de l'exécution. --<os>permet au système d'exploitation d'être utilisé comme condition pour l'application de profil au moment de l'exécution --<nom>est conditionnel au nom du système d'exploitation
• Le nom du système d'exploitation utilise la valeur qui peut être obtenue à partir de la propriété système ʻos.name`. ――Il semble qu'il n'y ait pas de distinction entre les majuscules et les minuscules --En plus du nom, vous pouvez spécifier les conditions suivantes
  • <family>
• Type d'OS
• Voir Règles intégrées Apache Maven Enforcer - Exiger la version du système d'exploitation pour une liste des valeurs possibles.
• Au fait, pour Linux, spécifiez ʻunix`.
  • <arch>
• Architecture du processeur --Spécifiez «x86» ou «amd64»
  • <version>
• Version OS
• Si vous spécifiez plusieurs de ces conditions, elles seront toutes combinées avec la condition AND.
• La valeur de l'environnement actuel peut être trouvée dans le [objectif d'affichage des informations](http: /) de maven-enforcer-plugin. Vous pouvez vérifier en exécutant /maven.apache.org/enforcer/maven-enforcer-plugin/display-info-mojo.html)

Résultat d'exécution

> mvn enforcer:display-info
...
[INFO] Maven Version: 3.6.3
[INFO] JDK Version: 11.0.6 normalized as: 11.0.6
[INFO] OS Info: Arch: amd64 Family: windows Name: windows 10 Version: 10.0

L'existence du fichier est une condition

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>Exists</id>
      <activation>
        <file>
          <exists>${basedir}/pom.xml</exists>
        </file>
      </activation>
      <properties>
        <message>Exists profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--<activation>spécifie<file>

Résultat d'exécution

> mvn antrun:run
...
     [echo] message = Exists profile!!

• Vous pouvez utiliser <fichier> pour utiliser la présence ou l'absence d'un fichier comme condition d'application d'un profil. --<existe>est défini à condition que le fichier existe --Utilisez <missing> si la condition est que le fichier n'existe pas --Dans la spécification du chemin de fichier, le paramètre intégré est $ {basedir} ou propriété système / propriété de requête? Il y a une limitation qu'il ne peut être utilisé
• Si vous écrivez $ {project.basedir} / pom.xml, cela ne sera pas bien jugé.

Vérifier les profils disponibles

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>foo</id>
      <properties>
        <message>foo profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>bar</id>
      <properties>
        <message>bar profile!!</message>
      </properties>
    </profile>
  </profiles>

  ...
</project>

--foo, bar, deux profils sont définis

Résultat d'exécution

> mvn help:all-profiles
...
[INFO] Listing Profiles for Project: example:hello:jar:1.0.0
  Profile Id: bar (Active: false , Source: pom)
  Profile Id: foo (Active: false , Source: pom)

• tous les profils dans maven-help-plugin -plugin / all-profiles-mojo.html) pour voir quels profils sont disponibles

Vérifiez le profil actif

Résultat d'exécution

> mvn -P foo help:active-profiles antrun:run
...
Active Profiles for Project 'example:hello:jar:1.0.0':

The following profiles are active:

 - foo (source: example:hello:1.0.0)
...
     [echo] message = foo profile!!

--Utilisez active-profiles pour voir quels profils sont actifs à l'exécution. ça peut ――Il peut être utile lors du débogage

Quand utiliser le profil

• Les profils vous permettent de créer différents résultats de construction pour chaque profil Pour cette raison, si le profil est trop diversifié, différents développeurs peuvent obtenir des résultats de construction différents.
• Il y avait une règle comme "Pour des raisons de développement, vous devez activer le profil" develop "et vous avez oublié de le spécifier.
• Les changements dans les résultats de compilation peuvent prêter à confusion
• Comme vous pouvez l'imaginer du fait que des conditions telles que «» peuvent être définies, je pense que le but initial du profil est d'absorber les différences dans l'environnement dans lequel la construction est effectuée. «Par conséquent, je pense qu'il vaut mieux éviter autant que possible de l'utiliser à d'autres fins (avis personnel).
• Par exemple, le profil ne peut pas être utilisé dans la méthode de commutation du fichier de paramètres utilisé pour le développement, l'environnement de vérification et l'environnement de production.
• Je pense qu'il est préférable d'utiliser des variables d'environnement comme moyen de changer les paramètres d'application pour chaque environnement de nos jours. --Référence: III. Paramètres | L'application Twelve-Factor (traduction japonaise)

Faites votre propre prise

• Vous pouvez créer votre propre plug-in
• Si les plugins de ʻorg.apache.maven.pluginsou decom.codehaus.mojo` ne répondent pas à vos objectifs, vous devrez créer les vôtres.

Hello World

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello-maven-plugin</artifactId>
  <version>1.0.0</version>
  <packaging>maven-plugin</packaging>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.apache.maven</groupId>
      <artifactId>maven-plugin-api</artifactId>
      <version>3.6.3</version>
    </dependency>

    <dependency>
      <groupId>org.apache.maven.plugin-tools</groupId>
      <artifactId>maven-plugin-annotations</artifactId>
      <version>3.6.0</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-plugin-plugin</artifactId>
        <version>3.6.0</version>
      </plugin>
    </plugins>
  </build>
</project>

--Définissez le packaging sur maven-plugin --Définissez les deux suivants comme dépendances - org.apache.maven:maven-plugin-api - org.apache.maven.plugin-tools:maven-plugin-annotations

• Ceci est spécifié dans la portée fournie --Réglage de maven-plugin-plugin` --Lorsque vous essayez de compiler avec Java 11, il semble que vous obtiendrez une erreur à moins que vous ne mettiez à jour la version de ce plug-in.

HelloMojo.java

package example;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.Mojo;

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {

    public void execute() throws MojoExecutionException {
        getLog().info("Hello Custom Plugin!");
    }
}

--ʻAbstractMojoCréer une classe en héritant de la classe --Cette classeHelloPlugincorrespond à un objectif ―― Implémentez le traitement du plug-in dans la méthode execute ()

• Les méta-informations d'objectif sont définies avec l'annotation @ Mojo. --name devient le nom de l'objectif

Construire

> mvn install
...

―― Exécutez la phase ʻinstall` pour installer le plugin créé dans votre référentiel local

• Essayez d'utiliser le plug-in installé dans un autre projet

pom.xml(Autres projets)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
      </plugin>
    </plugins>
  </build>
</project>

--Le hello-maven-plugin est réglé sur <plugin>

Résultat d'exécution

> mvn hello:hello
...
[INFO] Hello Custom Plugin!

• J'ai pu exécuter mon propre plug-in

Nom du plug-in (artifactId)

pom.xml

...
  <groupId>example</groupId>
  <artifactId>hello-maven-plugin</artifactId>
  <version>1.0.0</version>
...

• Il est habituel de définir ʻartifactIdde votre propre plug-in surXXX-maven-plugin. --Si vous définissez ʻartifactId sur ce modèle, la méta définition sera automatiquement créée avec la partie XXX comme préfixe du plug-in.
• Essai, vérifiez à l'intérieur du fichier jar créé

Contenu du pot

hello-1.0.0.jar/
 |-example/
 `-META-INF/
   |-MANIFEST.MF
   `-maven/
     |-example/
     `-plugin.xml

• En regardant le contenu de ce plugin.xml, il ressemble à ceci:

plugin.xml

...
<plugin>
  <name>hello-maven-plugin</name>
  <description></description>
  <groupId>example</groupId>
  <artifactId>hello-maven-plugin</artifactId>
  <version>1.0.0</version>
  <goalPrefix>hello</goalPrefix>
  <isolatedRealm>false</isolatedRealm>
  <inheritedByDefault>true</inheritedByDefault>
...

--<goalPrefix>est maintenant bonjour

• Cela permet à ce plug-in d'être préfixé par bonjour: <objectif>
• Si vous avez ʻartifactId appelé foo-maven-plugin, le préfixe est foo`.

Mojo

• La classe qui implémente les objectifs du plug-in de Maven s'appelle ** Mojo (Maven Old Java Object) **.
• Lors de la lecture de la documentation de Maven, le terme Mojo apparaît ici et là. Dans ce cas, vous pouvez le considérer comme une classe qui met en œuvre des objectifs.

Définir les paramètres

HelloMojo.java

package example;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.Mojo;
import org.apache.maven.plugins.annotations.Parameter;

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter
    private String message;

    public void execute() throws MojoExecutionException {
        getLog().info("message = " + message);
    }
}

• Ajout d'un champ message à Mojo et annotation avec @ Parameter --Getter et Setter ne sont pas définis

pom.xml(Un autre projet)

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
        <configuration>
          <message>Hello World!!</message>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--<configuration>déclare le même élément que le nom du champ Mojo

Résultat d'exécution

> mvn hello:hello
...
[INFO] message = Hello World!!

• Le champ message déclaré dans Mojo peut maintenant être spécifié comme paramètre.
• D'ailleurs, dans cet état, vous ne pouvez pas spécifier la valeur dans les propriétés système.

Autoriser la spécification des paramètres dans les propriétés système

HelloMojo.java

package example;
...

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter(property="hello.message")
    private String message;

    public void execute() throws MojoExecutionException {
        getLog().info("message = " + message);
    }
}

--Définissez property of @ Parameter sur le nom spécifié dans les propriétés système.

pom.xml (projet séparé)

...
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
      </plugin>
...

--Ne spécifiez pas <configuration> (s'il est défini, cela aura priorité)

Résultat d'exécution

> mvn hello:hello -Dhello.message="HELLO WORLD!!"
...
[INFO] message = HELLO WORLD!!

• Vous pouvez maintenant définir la valeur via les propriétés système

Définir les valeurs par défaut des paramètres

HelloMojo.java

package example;
...

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter(property="hello.message", defaultValue="Hello Custom Plugin!!")
    private String message;

    public void execute() throws MojoExecutionException {
        getLog().info("message = " + message);
    }
}

• L'annotation @ Parameter`` defaultValue peut déclarer la valeur par défaut pour ce paramètre.

pom.xml(Un autre projet)

...
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
      </plugin>
...

--<configuration>n'est pas configuré

Résultat d'exécution

> mvn hello:hello
...
[INFO] message = Hello Custom Plugin!!
...

> mvn hello:hello -Dhello.message=OVERRIDE!!
...
[INFO] message = OVERRIDE!!

--Si rien n'est défini, vous pouvez voir que la valeur définie dans defaultValue est adoptée.

Utilisez une expression pour la valeur par défaut

HelloMojo.java

package example;
...

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter(defaultValue="${hello.mojo.message}")
    private String message;

    public void execute() throws MojoExecutionException {
        getLog().info("message = " + message);
    }
}

--La valeur de defaultValue peut être décrite comme $ {...}

• Voir PluginParameterExpressionEvaluator Javadoc pour les valeurs qui peuvent être référencées dans les expressions.
• Vous pouvez également vous référer aux propriétés système et aux propriétés du projet (<properties>)

pom.xml(Un autre projet)

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <properties>
    <hello.mojo.message>Project Property</hello.mojo.message>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
      </plugin>
    </plugins>  
  </build>
</project>

--Déclarer une valeur dans <properties> avec la même clé que celle déclarée dans l'expression defaultValue

Résultat d'exécution

> mvn hello:hello
...
[INFO] message = Project Property
...

> mvn hello:hello -Dhello.mojo.message="System Property"
...
[INFO] message = System Property

--La valeur déclarée dans <properties> est définie dans le paramètre messge --Peut également être remplacé par les propriétés système

Types pouvant être utilisés pour les paramètres

• Les types de paramètres peuvent être déclarés avec différents types, pas seulement String

HelloMojo.java

package example;

import java.io.File;
import java.net.URL;
import java.util.Date;
import java.util.List;
import java.util.Map;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.logging.Log;
import org.apache.maven.plugins.annotations.Mojo;
import org.apache.maven.plugins.annotations.Parameter;

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter
    private int intValue;
    @Parameter
    private long longValue;
    @Parameter
    private boolean booleanValue;
    @Parameter
    private double doubleValue;
    @Parameter
    private Date dateValue;
    @Parameter
    private File fileValue;
    @Parameter
    private URL urlValue;
    @Parameter
    private HelloEnum enumValue;
    @Parameter
    private List<String> listValues;
    @Parameter
    private Map<String, String> mapValue;

    public void execute() throws MojoExecutionException {
        Log log = getLog();
        log.info("intValue=" + intValue);
        log.info("longValue=" + longValue);
        log.info("booleanValue=" + booleanValue);
        log.info("doubleValue=" + doubleValue);
        log.info("dateValue=" + dateValue);
        log.info("fileValue=" + fileValue);
        log.info("urlValue=" + urlValue);
        log.info("enumValue=" + enumValue);
        log.info("listValues=" + listValues);
        log.info("mapValue=" + mapValue);
    }

    public enum HelloEnum {
        HELLO,
        WORLD;
    }
}

• Les paramètres sont définis avec différents types

pom.xml(Un autre projet)

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
        <configuration>
          <intValue>123</intValue>
          <longValue>1234567890</longValue>
          <booleanValue>true</booleanValue>
          <doubleValue>1234.5678</doubleValue>
          <dateValue>2019-10-20 12:13:14</dateValue>
          <fileValue>foo/bar</fileValue>
          <urlValue>https://www.google.co.jp/</urlValue>
          <enumValue>HELLO</enumValue>
          <listValues>
            <aaa>fizz</aaa>
            <bbb>buzz</bbb>
          </listValues>
          <mapValue>
            <foo>FOO</foo>
            <bar>BAR</bar>
          </mapValue>
        </configuration>
      </plugin>
    </plugins>  
  </build>
</project>

Résultat d'exécution

> mvn hello:hello
...
[INFO] intValue=123
[INFO] longValue=1234567890
[INFO] booleanValue=true
[INFO] doubleValue=1234.5678
[INFO] dateValue=Sun Oct 20 12:13:14 JST 2019
[INFO] fileValue=F:\tmp\maven\hello\foo\bar
[INFO] urlValue=https://www.google.co.jp/
[INFO] enumValue=HELLO
[INFO] listValues=[fizz, buzz]
[INFO] mapValue={bar=BAR, foo=FOO}
...

• Les types primitifs tels que ʻint, long, float, double, boolean` peuvent être utilisés normalement
• La classe Wrapper est également possible --java.util.Date est spécifié dans l'un des formats suivants --yyyy-MM-dd HH: mm: ss.S a (Exemple: 2005-10-06 2:22: 55.1 PM) --yyyy-MM-dd HH: mm: ssa (Exemple: 2005-10-06 2:22:55 PM) ――Cependant, même s'ils ne correspondent pas exactement, ils peuvent être analysés de manière flexible (AM et PM peuvent être omis, mais l'heure ne peut pas être omise). --java.io.File traite la valeur comme un chemin --java.net.URL traite la valeur comme une URL
• Dans le cas du type enum, il peut être défini en spécifiant la même valeur que les constantes répertoriées.
• Dans le cas de List, si vous énumérez des éléments avec des noms arbitraires en écrivant le même élément que le nom du paramètre, il semble qu'il sera traité comme un élément de List.
• Habituellement, il est plus facile d'écrire comme <listValues> <listValue> ...
• Dans le cas de Map, le nom de l'élément imbriqué est la clé et la valeur de l'élément est la valeur. --Bien que la vérification soit omise, java.util.Properties peut être utilisé de la même manière.

Associer la phase par défaut

HelloMojo.java

package example;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.LifecyclePhase;
import org.apache.maven.plugins.annotations.Mojo;

@Mojo(name="hello", defaultPhase=LifecyclePhase.VALIDATE)
public class HelloMojo extends AbstractMojo {

    public void execute() throws MojoExecutionException {
        getLog().info("Hello Mojo!!");
    }
}

• Vous pouvez spécifier la phase par défaut avec defaultPhase of @ Mojo --Utilisez le type d'énumération LifecyclePhase pour spécifier la phase --Ici, il est lié à la phase valider

pom.xml(Un autre projet)

...
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
        <executions>
          <execution>
            <goals>
              <goal>hello</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
...

--hello Seul le but est déclaré et les phases ne sont pas liées.

Résultat d'exécution(Un autre projet)

> mvn validate
...
[INFO] Hello Mojo!!

--L'objectif «hello» est en cours d'exécution lors de l'exécution de la phase de «validation».

Supprimer le produit

Structure des dossiers

|-pom.xml
`-target/

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

Résultat d'exécution

> mvn clean
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hello ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

Structure des dossiers (après exécution)

`-pom.xml

• objectif propre de maven-clean-plugin Vous pouvez supprimer tous les produits du projet en exécutant plugin / clean-mojo.html)
• La phase «propre» est spécifiée ici. --L'objectif nettoyer est associé à la phase propre par défaut (déroutant) --Par défaut, les dossiers suivants sont ciblés pour la suppression
  • ${project.build.directory}
  • ${project.build.outputDirectory}
  • ${project.build.testOutputDirectory}
  • ${project.reporting.outputDirectory} -- $ {project.basedir} / target sera supprimé sauf si vous avez changé le chemin du dossier ci-dessus.

Ajouter le dossier à supprimer

Structure des dossiers

|-pom.xml
|-target/
`-foo/

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-clean-plugin</artifactId>
        <version>3.1.0</version>
        <configuration>
          <filesets>
            <fileset>
              <directory>${project.basedir}/foo</directory>
            </fileset>
          </filesets>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Ajout de <filesets> et ajout du dossier foo à supprimer

Résultat d'exécution

> mvn clean
...
[INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ hello ---
[INFO] Deleting ...\foo (includes = [], excludes = [])
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

Structure des dossiers (après exécution)

`-pom.xml

• Non seulement target mais foo a été supprimé
• Vous pouvez ajouter des dossiers et des fichiers à supprimer avec le paramètre filesets. --<filesets>spécifie la collection de Fileset Faire --Il semble que vous puissiez affiner les fichiers non seulement avec <directory> '' mais aussi avec '' et ` '' (je ne l'ai pas essayé).

Référence et table des matières des documents officiels

Il est trop difficile de comprendre où et quelles informations se trouvent, alors je vais les trier </ del>

• POM
  • Maven – POM Reference
  • Maven – Introduction to the POM
  • Maven Model Builder – Super POM
  • Apache Maven Archiver – Reference
• Brancher
  • Maven – Available Plugins
  • Maven – Guide to Configuring Plug-ins
  • Maven – Guide to Developing Java Plugins
  • Mojo – Plugins --Construire le cycle de vie
  • Maven – Introduction to the Build Lifecycle
  • Lifecycle Reference
  • Maven Core – Plugin Bindings for Default Lifecycle Reference --Profil
  • Maven – Introduction to build profiles -Résolution de dépendance
  • Maven – Introduction to the Dependency Mechanism
• Structure du dossier
  • Maven – Introduction to the Standard Directory Layout
• Javadoc
  • Maven Model API