Avanceret Maven-projektopbygning

1.1 Liste over plugins til at bygge i Maven

Samlingen i Maven kan konfigureres meget fleksibelt. Maven-udviklere har specielt lavet snesevis af plugins, ved hjælp af hvilke du meget fleksibelt kan konfigurere forskellige builds. De mest populære af dem er vist i tabellen nedenfor:

Hvert plugin er interessant på sin egen måde, men vi bliver nødt til at analysere dem alle. Lad os starte med det vigtigste - kompileringsstyringsplugin'et.

1.2 Kompileringsplugin maven-compiler-plugin

Det mest populære plugin, der giver dig mulighed for at kontrollere versionen af ​​compileren og bruges i næsten alle projekter, er maven-compiler-plugin. Det har standardindstillinger, men i næsten alle projekter skal de indstilles igen.

I den enkleste version, i plug-in'et, skal du angive versionen af ​​Java-kildekoden og versionen af ​​Java-maskinen, under hvilken samlingen udføres:

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

I eksemplet ovenfor satte vi tre Java-kompilerindstillinger: source, targetog encoding.

Parameteren sourcegiver os mulighed for at indstille Java-versionen for vores kilder. Parameteren targeter den version af Java-maskinen, som du vil kompilere klasserne under. Hvis der ikke er angivet nogen kode eller Java-maskineversion, er standarden 1.3

Endelig giver parameteren encodingdig mulighed for at angive kodningen af ​​Java-filer. Vi angav UTF-8. Nu er næsten alle kilder gemt i UTF-8. Men hvis denne parameter ikke er angivet, vil den aktuelle kodning af operativsystemet blive valgt. For Windows er dette kodningen Windows-1251.

Der er også tilfælde, hvor byggecomputeren har flere versioner af Java installeret: at bygge forskellige moduler og/eller forskellige projekter. I dette tilfælde JAVA_HOMEkan kun stien til en af ​​dem angives i variablen.

Derudover er der forskellige implementeringer af Java-maskinen: OpenJDK, OracleJDK, Amazon JDK. Og jo større projektet er, jo mere kompleks er dets struktur. Men du kan udtrykkeligt indstille stien til javac-kompileren for plugin'et ved hjælp af tagget . Det blev tilføjet specielt til denne lejlighed.

Pluginnet maven-compiler-pluginhar to mål:

• compiler:compile– kompilering af kilder, som standard forbundet med kompileringsfasen
• compiler:testCompile– kompilering af test, som standard er det forbundet med test-kompileringsfasen.

Du kan også angive en liste over argumenter, der skal sendes til javac-kompileren på kommandolinjen:

<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 til oprettelse af jar-fil maven-jar-plugin

Hvis du vil bygge dit eget jar-bibliotek med Maven, skal du bruge maven-jar-plugin. Dette plugin gør en masse nyttige ting.

Et eksempel på sådan et 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>

For det første kan den bruges til at angive, hvilke filer der skal ind i biblioteket, og hvilke der ikke vil. Ved hjælp af tags <include>i sektionen <includes>kan du angive en liste over mapper, hvis indhold skal tilføjes til biblioteket .

For det andet skal hver jar have et manifest ( MANIFEST.MF fil ). Selve plugin'et vil placere det på det rigtige sted i biblioteket, du skal blot angive, hvilken vej du skal tage det. Taget bruges til dette <manifestFile>.

Endelig kan plugin'et generere et manifest på egen hånd. For at gøre dette skal du i stedet for et tag <manifestFile>tilføje et tag <manifest>og angive data for det fremtidige manifest i det. Eksempel:

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

Tagget <addClasspath>angiver, om der skal føjes til manifestet CLASSPATH.

Tagget <classpathPrefix>giver dig mulighed for at tilføje et præfiks (i eksemplet lib) før hver ressource. Angivelse af et præfiks i <classpathPrefix>giver dig mulighed for at placere afhængigheder i en separat mappe.

Ja, du kan placere biblioteker i et andet bibliotek. Og der er mange overraskelser, der venter på dig, når du skal passere stien til egenskabsfilen et eller andet sted, som er i jar-biblioteket, som er i jar-biblioteket.

Endelig peger tagget <mainClass>på den primære eksekverbare klasse. "Hvad er den vigtigste eksekverbare klasse? ", - du spørger. Og sagen er, at en Java-maskine kan køre et program, der ikke kun er specificeret af en Java-klasse, men også af en jar-fil. Og det er til denne sag, at hovedstartklassen er nødvendig.

1.4 Byg nummergenereringsplugin buildnumber-maven-plugin

Meget ofte indeholder jar-biblioteker og krigsfiler information med navnet på projektet og dets version samt versionen af ​​samlingen. Dette er ikke kun nyttigt til styring af afhængigheder, men det forenkler også test: det er tydeligt i hvilken version af biblioteket fejlen er rettet, og i hvilken den er tilføjet.

Oftest løses denne opgave sådan - de opretter en speciel fil application.properties, der indeholder alle de nødvendige oplysninger og inkluderer den i forsamlingen. Du kan også konfigurere build-scriptet, så dataene fra denne fil migrerer til MANIFEST.MFosv.

Men det mest interessante er, at Maven har et specielt plugin, der kan generere sådan en application.properties-fil. For at gøre dette skal du oprette en sådan fil og udfylde den med specielle dataskabeloner. Eksempel:

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

Værdierne for alle tre parametre vil blive erstattet på byggestadiet.

Parametre pom.nameog pom.versionvil blive taget direkte fra pom.xml. Og for at generere et unikt build-nummer i Maven, er der et særligt plugin - buildnumber-maven-plugin. Se eksempel nedenfor:

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

I eksemplet ovenfor sker der tre vigtige ting. Først er selve plugin'et angivet til indstilling af assembly-versionen . For det andet er det specificeret, at det vil køre under valideringsfasen (den allerførste fase) og generere et buildnummer - ${buildNumber}.

Og for det tredje er formatet på dette samlingsnummer angivet, som er limet sammen fra flere dele . Dette er versionen af ​​projektet project.versionog det aktuelle tidspunkt givet af skabelonen. Skabelonformatet er specificeret af Java-klassen MessageFormat.