Construction avancée du projet Maven

1.1 Liste des plugins à construire dans Maven

L'assemblage dans Maven peut être configuré de manière très flexible. Les développeurs Maven ont spécialement créé des dizaines de plugins, à l'aide desquels vous pouvez configurer de manière très flexible diverses versions. Les plus connus d'entre eux sont présentés dans le tableau ci-dessous :

Chaque plugin est intéressant à sa manière, mais il va falloir tous les analyser. Commençons par l'essentiel - le plugin de gestion de compilation.

1.2 Plug-in de compilation maven-compiler-plugin

Le plugin le plus populaire qui vous permet de contrôler la version du compilateur et qui est utilisé dans presque tous les projets est le maven-compiler-plugin. Il a des paramètres par défaut, mais dans presque tous les projets, ils doivent être définis à nouveau.

Dans la version la plus simple, dans le plug-in, il faut préciser la version du code source Java et la version de la machine Java sous laquelle s'effectue l'assemblage :

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.2</version>
    <configuration>
        <source>1.11</source>
        <target>1.13</target>
        <encoding>UTF-8</encoding>
    </configuration>
</plugin>

Dans l'exemple ci-dessus, nous définissons trois options du compilateur Java : source, targetet encoding.

Le paramètre sourcenous permet de définir la version Java de nos sources. Le paramètre targetest la version de la machine Java sous laquelle vous souhaitez compiler les classes. Si aucun code ou version de machine Java n'est spécifié, la valeur par défaut est 1.3

Enfin, le paramètre encodingpermet de spécifier l'encodage des fichiers Java. Nous avons indiqué UTF-8. Désormais, presque toutes les sources sont stockées au format UTF-8. Mais si ce paramètre n'est pas spécifié, l'encodage actuel du système d'exploitation sera sélectionné. Pour Windows, il s'agit de l'encodage Windows-1251.

Il existe également des cas où plusieurs versions de Java sont installées sur l'ordinateur de build : pour construire différents modules et/ou différents projets. Dans ce cas, JAVA_HOMEseul le chemin vers l'un d'entre eux peut être spécifié dans la variable.

De plus, il existe différentes implémentations de la machine Java : OpenJDK, OracleJDK, Amazon JDK. Et plus le projet est grand, plus sa structure est complexe. Mais vous pouvez explicitement définir le chemin vers le compilateur javac pour le plugin en utilisant la balise . Il a été ajouté spécialement pour cette occasion.

Le plugin maven-compiler-plugina deux objectifs :

• compiler:compile– compilation des sources, par défaut associée à la phase de compilation
• compiler:testCompile– compilation de tests, par défaut elle est associée à la phase test-compilation.

Vous pouvez également spécifier une liste d'arguments à transmettre au compilateur javac sur la ligne de commande :

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.2</version>
    <configuration>
        <compilerArgs>
            <arg>-verbose</arg>
            <arg>-Xlint:all,-options,-path<arg>
        </compilerArgs>
    </configuration>
</plugin>

1.3 Plugin pour créer un fichier jar maven-jar-plugin

Si vous souhaitez créer votre propre bibliothèque jar avec Maven, vous aurez besoin du plugin maven-jar-plugin. Ce plugin fait beaucoup de choses utiles.

Un exemple d'un tel plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        <includes>
            <include>**/properties/*</include>
        </includes>
        <archive>
           <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
        </archive>
    </configuration>
</plugin>

Tout d'abord, il peut être utilisé pour spécifier quels fichiers iront dans la bibliothèque et lesquels ne le seront pas. À l'aide de balises <include>dans la section, <includes>vous pouvez spécifier une liste de répertoires dont le contenu doit être ajouté à la bibliothèque .

Deuxièmement, chaque pot doit avoir un manifeste ( fichier MANIFEST.MF ). Le plugin lui-même le placera au bon endroit dans la bibliothèque, il vous suffit de spécifier le chemin à suivre. La balise est utilisée pour cela <manifestFile>.

Enfin, le plugin peut générer lui-même un manifeste. Pour ce faire, au lieu d'une balise, <manifestFile>vous devez ajouter une balise <manifest>et y spécifier des données pour le futur manifeste. Exemple:

<configuration>
    <archive>
        <manifest>
            <addClasspath>true</addClasspath>
            <classpathPrefix>lib/</classpathPrefix>
            <mainClass>com.codegym.MainApplication</mainClass>
        </manifest>
    </archive>
</configuration>

La balise <addClasspath>spécifie s'il faut ajouter au manifeste CLASSPATH.

La balise <classpathPrefix>permet d'ajouter un préfixe (dans l'exemple lib) avant chaque ressource. La spécification d'un préfixe dans <classpathPrefix>vous permet de placer les dépendances dans un dossier séparé.

Oui, vous pouvez placer des bibliothèques dans une autre bibliothèque. Et de nombreuses surprises vous attendent lorsque vous devez transmettre le chemin d'accès au fichier de propriétés quelque part, qui se trouve dans la bibliothèque jar, qui se trouve dans la bibliothèque jar.

Enfin, la balise <mainClass>pointe vers la classe exécutable principale. « Quelle est la classe exécutable principale ? ", - tu demandes. Et le fait est qu'une machine Java peut exécuter un programme spécifié non seulement par une classe Java, mais également par un fichier jar. Et c'est pour ce cas que la classe de départ principale est nécessaire.

1.4 Plugin de génération de numéro de build buildnumber-maven-plugin

Très souvent, les bibliothèques jar et les fichiers war incluent des informations avec le nom du projet et sa version, ainsi que la version de l'assembly. Non seulement cela est utile pour gérer les dépendances, mais cela simplifie également les tests : il est clair dans quelle version de la bibliothèque l'erreur est corrigée et dans laquelle elle est ajoutée.

Le plus souvent, cette tâche est résolue comme ceci - ils créent un fichier spécial application.propertiescontenant toutes les informations nécessaires et l'incluent dans l'assemblage. Vous pouvez également configurer le script de génération afin que les données de ce fichier migrent vers MANIFEST.MFetc.

Mais ce qui est le plus intéressant, c'est que Maven a un plugin spécial qui peut générer un tel fichier application.properties. Pour ce faire, vous devez créer un tel fichier et le remplir avec des modèles de données spéciaux. Exemple:

# application.properties
app.name=${pom.name}
app.version=${pom.version}
app.build=${buildNumber}

Les valeurs des trois paramètres seront remplacées au stade de la construction.

Les paramètres pom.nameet pom.versionseront extraits directement de pom.xml. Et pour générer un numéro de build unique dans Maven, il existe un plugin spécial - buildnumber-maven-plugin. Voir exemple ci-dessous :

<packaging>war</packaging>
<version>1.0</version>
<plugins>
    <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>buildnumber-maven-plugin</artifactId>
        <version>1.2</version>
        <executions>
            <execution>
                <phase>validate</phase>
                <goals>
                    <goal>create</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <revisionOnScmFailure>true</revisionOnScmFailure>
            <format>{0}-{1,date,yyyyMMdd}</format>
            <items>
                 <item>${project.version}</item>
                 <item>timestamp</item>
            </items>
        </configuration>
    </plugin>
</plugins>

Dans l'exemple ci-dessus, trois choses importantes se produisent. Tout d'abord, le plugin lui-même est spécifié pour définir la version de l'assembly . Dans un second temps, il est précisé qu'il s'exécutera lors de la phase de validation (la toute première phase) et générera un numéro de build - ${buildNumber}.

Et troisièmement, le format de ce numéro d'assemblage est indiqué, qui est collé à partir de plusieurs pièces . Il s'agit de la version du projet project.versionet de l'heure actuelle données par le modèle. Le format du modèle est spécifié par la classe Java MessageFormat.