Avansert Maven-prosjektbygging

1.1 Liste over plugins å bygge i Maven

Monteringen i Maven kan konfigureres svært fleksibelt. Maven-utviklere har spesiallaget dusinvis av plugins, som du kan bruke til å konfigurere forskjellige bygg veldig fleksibelt. De mest populære av dem er vist i tabellen nedenfor:

Hver plugin er interessant på sin egen måte, men vi må analysere dem alle. La oss starte med det viktigste - kompileringsadministrasjonsplugin.

1.2 Kompileringsplugin maven-compiler-plugin

Den mest populære plugin som lar deg kontrollere versjonen av kompilatoren og brukes i nesten alle prosjekter er maven-compiler-plugin. Den har standardinnstillinger, men i nesten alle prosjekter må de settes på nytt.

I den enkleste versjonen, i plugin-modulen, må du spesifisere versjonen av Java-kildekoden og versjonen av Java-maskinen som monteringen utføres under:

<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-kompilatoralternativer: source, targetog encoding.

Parameteren sourcelar oss angi Java-versjonen for våre kilder. Parameteren targeter versjonen av Java-maskinen du vil kompilere klassene under. Hvis ingen kode eller Java-maskinversjon er spesifisert, er standard 1.3

Til slutt lar parameteren encodingdeg spesifisere kodingen av Java-filer. Vi indikerte UTF-8. Nå er nesten alle kilder lagret i UTF-8. Men hvis denne parameteren ikke er spesifisert, vil gjeldende koding av operativsystemet bli valgt. For Windows er dette kodingen Windows-1251.

Det er også tilfeller når byggedatamaskinen har flere versjoner av Java installert: å bygge forskjellige moduler og/eller forskjellige prosjekter. I dette tilfellet JAVA_HOMEkan bare banen til en av dem spesifiseres i variabelen.

I tillegg er det forskjellige implementeringer av Java-maskinen: OpenJDK, OracleJDK, Amazon JDK. Og jo større prosjektet er, desto mer kompleks er strukturen. Men du kan eksplisitt angi banen til javac-kompilatoren for plugin ved å bruke taggen . Den ble lagt til spesielt for denne anledningen.

Programtillegget maven-compiler-pluginhar to mål:

• compiler:compile– kompilering av kilder, som standard knyttet til kompileringsfasen
• compiler:testCompile– kompilering av tester, som standard er det knyttet til test-kompileringsfasen.

Du kan også spesifisere en liste over argumenter som skal sendes til javac-kompilatoren 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 for å lage jar-fil maven-jar-plugin

Hvis du vil bygge ditt eget jar-bibliotek med Maven, trenger du maven-jar-plugin. Denne plugin-en gjør mange nyttige ting.

Et eksempel på en slik 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 brukes til å spesifisere hvilke filer som skal gå inn i biblioteket og hvilke som ikke vil. Ved å bruke tagger <include>i seksjonen <includes>kan du spesifisere en liste over kataloger hvis innhold må legges til i biblioteket .

For det andre må hver jar ha et manifest ( MANIFEST.MF- fil ). Programtillegget i seg selv vil plassere det på riktig sted i biblioteket, du trenger bare å spesifisere hvilken vei du skal ta det. Taggen brukes til dette <manifestFile>.

Til slutt kan plugin generere et manifest på egen hånd. For å gjøre dette, i stedet for en tag, <manifestFile>må du legge til en tag <manifest>og spesifisere data for det fremtidige manifestet i den. Eksempel:

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

Taggen <addClasspath>angir om den skal legges til i manifestet CLASSPATH.

Taggen <classpathPrefix>lar deg legge til et prefiks (i eksemplet lib) før hver ressurs. Ved å spesifisere et prefiks i <classpathPrefix>kan du plassere avhengigheter i en egen mappe.

Ja, du kan plassere biblioteker i et annet bibliotek. Og det er mange overraskelser som venter på deg når du trenger å sende stien til egenskapsfilen et sted, som er i jar-biblioteket, som er i jar-biblioteket.

Til slutt peker taggen <mainClass>til den kjørbare hovedklassen. "Hva er den viktigste kjørbare klassen? ", - du spør. Og saken er at en Java-maskin kan kjøre et program som er spesifisert ikke bare av en Java-klasse, men også av en jar-fil. Og det er for dette tilfellet hovedstartklassen trengs.

1.4 Bygg nummergenereringsplugin buildnumber-maven-plugin

Svært ofte inkluderer jar-biblioteker og krigsfiler informasjon med navnet på prosjektet og dets versjon, samt versjonen av forsamlingen. Ikke bare er dette nyttig for å administrere avhengigheter, men det forenkler også testing: det er tydelig i hvilken versjon av biblioteket feilen er rettet og i hvilken den er lagt til.

Oftest løses denne oppgaven slik - de lager en spesiell fil application.propertiessom inneholder all nødvendig informasjon og inkluderer den i forsamlingen. Du kan også konfigurere byggeskriptet slik at dataene fra denne filen migrerer til MANIFEST.MFosv.

Men det som er mest interessant er at Maven har en spesiell plugin som kan generere en slik application.properties-fil. For å gjøre dette må du opprette en slik fil og fylle den med spesielle datamaler. Eksempel:

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

Verdiene til alle tre parameterne vil bli erstattet på byggestadiet.

Parametre pom.nameog pom.versionvil bli tatt direkte fra pom.xml. Og for å generere et unikt byggenummer i Maven, er det en spesiell 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 skjer tre viktige ting. Først er selve plugin-modulen spesifisert for å angi monteringsversjonen . For det andre er det spesifisert at det vil kjøre under valideringsfasen (den aller første fasen) og generere et byggenummer - ${buildNumber}.

Og for det tredje er formatet til dette monteringsnummeret angitt, som er limt sammen fra flere deler . Dette er versjonen av prosjektet project.versionog gjeldende tidspunkt gitt av malen. Malformatet er spesifisert av Java-klassen MessageFormat.