Avancerat Maven-projektbygge

1.1 Lista över plugins att bygga i Maven

Monteringen i Maven kan konfigureras mycket flexibelt. Maven-utvecklare har speciellt skapat dussintals plugins, med hjälp av vilka du mycket flexibelt kan konfigurera olika builds. De mest populära av dem visas i tabellen nedan:

Varje plugin är intressant på sitt sätt, men vi måste analysera dem alla. Låt oss börja med det viktigaste - plugin för kompileringshantering.

1.2 Kompileringsplugin maven-compiler-plugin

Den mest populära plugin som låter dig kontrollera versionen av kompilatorn och som används i nästan alla projekt är maven-compiler-plugin. Den har standardinställningar, men i nästan varje projekt måste de ställas in igen.

I den enklaste versionen, i plug-in, måste du ange versionen av Java-källkoden och versionen av Java-maskinen under vilken monteringen utförs:

<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 exemplet ovan ställer vi in ​​tre Java-kompilatoralternativ: source, targetoch encoding.

Parametern sourcelåter oss ställa in Java-versionen för våra källor. Parametern targetär versionen av Java-maskinen som du vill kompilera klasserna under. Om ingen kod eller Java-maskinversion anges är standard 1.3

Slutligen låter parametern encodingdig ange kodningen för Java-filer. Vi angav UTF-8. Nu är nästan alla källor lagrade i UTF-8. Men om denna parameter inte är specificerad, kommer den aktuella kodningen av operativsystemet att väljas. För Windows är detta kodningen Windows-1251.

Det finns också fall då byggdatorn har flera versioner av Java installerade: att bygga olika moduler och/eller olika projekt. I det här fallet JAVA_HOMEkan endast sökvägen till en av dem anges i variabeln.

Dessutom finns det olika implementeringar av Java-maskinen: OpenJDK, OracleJDK, Amazon JDK. Och ju större projektet är, desto mer komplex struktur. Men du kan uttryckligen ställa in sökvägen till javac-kompilatorn för insticksprogrammet med taggen . Den lades till speciellt för detta tillfälle.

Pluginet maven-compiler-pluginhar två mål:

• compiler:compile– sammanställning av källor, som standard kopplat till kompileringsfasen
• compiler:testCompile– sammanställning av tester, som standard är den associerad med testkompileringsfasen.

Du kan också ange en lista med argument som ska skickas till javac-kompilatorn på kommandoraden:

<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 för att skapa jar-fil maven-jar-plugin

Om du vill bygga ditt eget jar-bibliotek med Maven behöver du maven-jar-plugin. Denna plugin gör många användbara saker.

Ett exempel på ett sådant 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>

Först kan den användas för att specificera vilka filer som ska gå in i biblioteket och vilka som inte ska göra det. Med hjälp av taggar <include>i avsnittet <includes>kan du ange en lista över kataloger vars innehåll måste läggas till i biblioteket .

För det andra måste varje jar ha ett manifest ( MANIFEST.MF- fil ) . Insticksprogrammet i sig kommer att placera det på rätt plats i biblioteket, du behöver bara ange vilken väg du ska ta den. Taggen används för detta <manifestFile>.

Slutligen kan plugin-programmet generera ett manifest på egen hand. För att göra detta, istället för en tagg, <manifestFile>måste du lägga till en tagg <manifest>och ange data för det framtida manifestet i den. Exempel:

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

Taggen <addClasspath>anger om den ska läggas till i manifestet CLASSPATH.

Taggen <classpathPrefix>låter dig lägga till ett prefix (i exemplet lib) före varje resurs. Genom att ange ett prefix i <classpathPrefix>kan du placera beroenden i en separat mapp.

Ja, du kan placera bibliotek i ett annat bibliotek. Och det finns många överraskningar som väntar på dig när du behöver passera sökvägen till egenskapsfilen någonstans, som finns i jar-biblioteket, som finns i jar-biblioteket.

Slutligen pekar taggen <mainClass>på den huvudsakliga körbara klassen. "Vilken är den huvudsakliga körbara klassen? ", - du frågar. Och grejen är att en Java-maskin kan köra ett program som inte bara specificeras av en Java-klass, utan också av en jar-fil. Och det är för det här fallet som huvudstartklassen behövs.

1.4 Bygg nummergenereringsplugin buildnumber-maven-plugin

Mycket ofta innehåller jar-bibliotek och krigsfiler information med namnet på projektet och dess version, såväl som versionen av sammansättningen. Detta är inte bara användbart för att hantera beroenden, utan det förenklar också testning: det är tydligt i vilken version av biblioteket felet är åtgärdat och i vilket det läggs till.

Oftast löses denna uppgift så här - de skapar en speciell fil application.propertiessom innehåller all nödvändig information och inkluderar den i monteringen. Du kan också konfigurera byggskriptet så att data från denna fil migreras till MANIFEST.MFetc.

Men det som är mest intressant är att Maven har en speciell plugin som kan generera en sådan application.properties-fil. För att göra detta måste du skapa en sådan fil och fylla den med speciella datamallar. Exempel:

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

Värdena för alla tre parametrarna kommer att ersättas i byggskedet.

Parametrar pom.nameoch pom.versionkommer att tas direkt från pom.xml. Och för att generera ett unikt byggnummer i Maven finns det en speciell plugin - buildnumber-maven-plugin. Se exempel nedan:

<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 exemplet ovan händer tre viktiga saker. Först anges själva plugin-programmet för att ställa in monteringsversionen . För det andra är det specificerat att det kommer att köras under valideringsfasen (den allra första fasen) och generera ett buildnummer - ${buildNumber}.

Och för det tredje anges formatet på detta monteringsnummer, som limmas ihop från flera delar . Detta är versionen av projektet project.versionoch den aktuella tiden som ges av mallen. Mallformatet specificeras av Java-klassen MessageFormat.