1.1 Lijst met plug-ins om in Maven te bouwen

De montage in Maven is zeer flexibel in te richten. Maven-ontwikkelaars hebben speciaal tientallen plug-ins gemaakt, waarmee je heel flexibel verschillende builds kunt configureren. De meest populaire worden weergegeven in de onderstaande tabel:

inpluggen Beschrijving
1 maven-compiler-plug-in Beheert Java-compilatie
2 maven-resources-plug-in Bepaalt de opname van resources in een assembly
3 maven source-plug-in Bepaalt of broncode wordt opgenomen in een assembly
4 maven-afhankelijkheids-plug-in Beheert het proces van het kopiëren van afhankelijkheidsbibliotheken
5 maven-jar-plug-in Plug-in voor het maken van het definitieve jar-bestand
6 Maven War-plug-in Plug-in voor het maken van het definitieve oorlogsbestand
7 maven-surefire-plug-in Beheert proefritten
8 buildnummer-maven-plugin Genereert een buildnummer

Elke plug-in is op zijn eigen manier interessant, maar we zullen ze allemaal moeten analyseren. Laten we beginnen met het belangrijkste: de plug-in voor compilatiebeheer.

1.2 Compilatie-plug-in maven-compiler-plug-in

De meest populaire plug-in waarmee u de versie van de compiler kunt bepalen en die in bijna alle projecten wordt gebruikt, is de maven-compiler-plugin. Het heeft standaardinstellingen, maar in bijna elk project moeten ze opnieuw worden ingesteld.

In de eenvoudigste versie, in de plug-in, moet u de versie van de Java-broncode opgeven en de versie van de Java-machine waaronder de assemblage wordt uitgevoerd:

<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>

In het bovenstaande voorbeeld hebben we drie Java-compileropties ingesteld: source, targeten encoding.

Met de parameter sourcekunnen we de Java-versie voor onze bronnen instellen. De parameter targetis de versie van de Java-machine waaronder u de klassen wilt compileren. Als er geen code of Java-machineversie is opgegeven, is de standaardwaarde 1.3

Ten slotte kunt u met de parameter encodingde codering van Java-bestanden specificeren. Wij hebben aangegeven UTF-8. Nu zijn bijna alle bronnen opgeslagen in UTF-8. Maar als deze parameter niet is opgegeven, wordt de huidige codering van het besturingssysteem geselecteerd. Voor Windows is dit de codering Windows-1251.

Er zijn ook gevallen waarin de bouwcomputer meerdere versies van Java heeft geïnstalleerd: om verschillende modules en/of verschillende projecten te bouwen. In dit geval JAVA_HOMEkan alleen het pad naar een ervan in de variabele worden opgegeven.

Daarnaast zijn er verschillende implementaties van de Java-machine: OpenJDK, OracleJDK, Amazon JDK. En hoe groter het project, hoe complexer de structuur. Maar u kunt het pad naar de javac-compiler voor de plug-in expliciet instellen met behulp van de tag . Het is speciaal voor deze gelegenheid toegevoegd.

De plug-in maven-compiler-pluginheeft twee doelen:

  • compiler:compile– compilatie van bronnen, standaard gekoppeld aan de compileerfase
  • compiler:testCompile– compilatie van tests, standaard gekoppeld aan de test-compileerfase.

U kunt ook een lijst met argumenten opgeven die moeten worden doorgegeven aan de javac-compiler op de opdrachtregel:

<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 Plug-in voor het maken van jar-bestand maven-jar-plugin

Als je je eigen jar-bibliotheek met Maven wilt bouwen, heb je de maven-jar-plug-in nodig. Deze plug-in doet veel nuttige dingen.

Een voorbeeld van zo'n plug-in:

<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>

Ten eerste kan het worden gebruikt om aan te geven welke bestanden naar de bibliotheek gaan en welke niet. Met behulp van tags <include>in de sectie <includes>kunt u een lijst met mappen specificeren waarvan de inhoud aan de bibliotheek moet worden toegevoegd .

Ten tweede moet elke jar een manifest hebben ( MANIFEST.MF -bestand ). De plug-in zelf zal het op de juiste plaats in de bibliotheek plaatsen, je hoeft alleen maar aan te geven welk pad je moet nemen. Hiervoor wordt de tag gebruikt <manifestFile>.

Ten slotte kan de plug-in zelf een manifest genereren. Om dit te doen, moet u in plaats van een tag <manifestFile>een tag toevoegen <manifest>en daarin gegevens specificeren voor het toekomstige manifest. Voorbeeld:

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

De tag <addClasspath>geeft aan of deze aan het manifest moet worden toegevoegd CLASSPATH.

Met de tag <classpathPrefix>kunt u een voorvoegsel toevoegen (in de voorbeeldlib) vóór elke bron. Door een voorvoegsel in op te geven, <classpathPrefix>kunt u afhankelijkheden in een aparte map plaatsen.

Ja, u kunt bibliotheken in een andere bibliotheek plaatsen. En er wachten veel verrassingen op je wanneer je ergens het pad naar het eigenschappenbestand moet doorgeven, dat zich in de jar-bibliotheek bevindt, die zich in de jar-bibliotheek bevindt.

Ten slotte verwijst de tag <mainClass>naar de belangrijkste uitvoerbare klasse. “Wat is de belangrijkste uitvoerbare klasse? ", - je vraagt. En het punt is dat een Java-machine een programma kan uitvoeren dat niet alleen wordt gespecificeerd door een Java-klasse, maar ook door een jar-bestand. En het is voor dit geval dat de belangrijkste startklasse nodig is.

1.4 Plugin voor het genereren van buildnummers buildnummer-maven-plugin

Heel vaak bevatten jar-bibliotheken en oorlogsbestanden informatie met de naam van het project en zijn versie, evenals de versie van de assembly. Dit is niet alleen handig voor het beheren van afhankelijkheden, maar het vereenvoudigt ook het testen: het is duidelijk in welke versie van de bibliotheek de fout is verholpen en waarin deze is toegevoegd.

Meestal wordt deze taak op deze manier opgelost: ze maken een speciaal bestand aan application.propertiesdat alle benodigde informatie bevat en nemen dit op in de montage. U kunt het build-script ook zo configureren dat de gegevens uit dit bestand migreren naar MANIFEST.MFenz.

Maar wat het meest interessant is, is dat Maven een speciale plug-in heeft die zo'n applicatie.properties-bestand kan genereren. Om dit te doen, moet u zo'n bestand maken en vullen met speciale gegevenssjablonen. Voorbeeld:

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

De waarden van alle drie de parameters worden in de bouwfase vervangen.

Parameters pom.nameen pom.versionworden rechtstreeks overgenomen uit pom.xml. En om een ​​uniek buildnummer in Maven te genereren, is er een speciale plug-in - buildnumber-maven-plugin. Zie voorbeeld hieronder:

<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>

In het bovenstaande voorbeeld gebeuren drie belangrijke dingen. Eerst wordt de plug-in zelf gespecificeerd voor het instellen van de assembly-versie . Ten tweede wordt gespecificeerd dat het zal draaien tijdens de validatiefase (de allereerste fase) en een buildnummer zal genereren - ${buildNumber}.

En ten derde wordt het formaat van dit montagenummer aangegeven, dat uit meerdere delen aan elkaar is gelijmd . Dit is de versie van het project project.versionen de huidige tijd gegeven door de sjabloon. Het sjabloonformaat wordt gespecificeerd door de Java-klasse MessageFormat.