Costruzione avanzata del progetto Maven

1.1 Elenco dei plugin da costruire in Maven

L'assemblaggio in Maven può essere configurato in modo molto flessibile. Gli sviluppatori Maven hanno creato appositamente dozzine di plug-in, utilizzando i quali è possibile configurare in modo molto flessibile varie build. I più popolari sono mostrati nella tabella seguente:

Ogni plugin è interessante a modo suo, ma dovremo analizzarli tutti. Cominciamo con la cosa principale: il plug-in di gestione della compilazione.

1.2 Plugin di compilazione maven-compiler-plugin

Il plugin più popolare che permette di controllare la versione del compilatore ed è usato in quasi tutti i progetti è il maven-compiler-plugin. Ha impostazioni predefinite, ma in quasi tutti i progetti devono essere reimpostate.

Nella versione più semplice, nel plug-in, è necessario specificare la versione del codice sorgente Java e la versione della macchina Java con cui viene eseguito l'assembly:

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

Nell'esempio precedente, impostiamo tre opzioni del compilatore Java: source, targete encoding.

Il parametro sourceci consente di impostare la versione Java per le nostre fonti. Il parametro targetè la versione della macchina Java in cui si desidera compilare le classi. Se non viene specificato alcun codice o versione della macchina Java, il valore predefinito è 1.3

Infine, il parametro encodingconsente di specificare la codifica dei file Java. Abbiamo indicato UTF-8. Ora quasi tutte le fonti sono archiviate in file UTF-8. Ma se questo parametro non è specificato, verrà selezionata la codifica corrente del sistema operativo. Per Windows, questa è la codifica Windows-1251.

Ci sono anche casi in cui il computer di compilazione ha diverse versioni di Java installate: per costruire moduli diversi e/o progetti diversi. In questo caso, JAVA_HOMEnella variabile può essere specificato solo il percorso di uno di essi.

Inoltre, esistono diverse implementazioni della macchina Java: OpenJDK, OracleJDK, Amazon JDK. E più grande è il progetto, più complessa è la sua struttura. Ma puoi impostare in modo esplicito il percorso del compilatore javac per il plug-in utilizzando il tag . È stato aggiunto appositamente per questa occasione.

Il plugin maven-compiler-pluginha due obiettivi:

• compiler:compile– compilazione dei sorgenti, associati di default alla fase di compilazione
• compiler:testCompile– compilazione dei test, di default è associato alla fase di compilazione dei test.

Puoi anche specificare un elenco di argomenti da passare al compilatore javac sulla riga di comando:

<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 per la creazione di file jar maven-jar-plugin

Se vuoi creare la tua libreria jar con Maven, avrai bisogno del plug-in maven-jar. Questo plugin fa molte cose utili.

Un esempio di tale 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>

Innanzitutto, può essere utilizzato per specificare quali file andranno nella libreria e quali no. Utilizzando i tag <include>nella sezione, <includes>puoi specificare un elenco di directory il cui contenuto deve essere aggiunto alla libreria .

In secondo luogo, ogni jar deve avere un manifest ( file MANIFEST.MF ). Il plugin stesso lo metterà nel posto giusto nella libreria, devi solo specificare quale percorso prenderlo. Il tag viene utilizzato per questo <manifestFile>.

Infine, il plug-in può generare un manifest da solo. Per fare ciò, invece di un tag, <manifestFile>è necessario aggiungere un tag <manifest>e specificare i dati per il futuro manifest in esso. Esempio:

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

Il tag <addClasspath>specifica se aggiungere al file manifest CLASSPATH.

Il tag <classpathPrefix>consente di aggiungere un prefisso (nell'esempio lib) prima di ogni risorsa. La specifica di un prefisso in <classpathPrefix>consente di posizionare le dipendenze in una cartella separata.

Sì, puoi posizionare le librerie all'interno di un'altra libreria. E ci sono molte sorprese che ti aspettano quando devi passare il percorso al file delle proprietà da qualche parte, che è nella libreria jar, che è nella libreria jar.

Infine, il tag <mainClass>punta alla classe eseguibile principale. “Qual è la classe eseguibile principale? ", - tu chiedi. E il fatto è che una macchina Java può eseguire un programma specificato non solo da una classe Java, ma anche da un file jar. Ed è per questo caso che serve la classe di partenza principale.

1.4 Plugin per la generazione del numero di build buildnumber-maven-plugin

Molto spesso, le librerie jar e i file war includono informazioni con il nome del progetto e la sua versione, oltre alla versione dell'assembly. Non solo è utile per gestire le dipendenze, ma semplifica anche il test: è chiaro in quale versione della libreria l'errore è stato corretto e in quale è stato aggiunto.

Molto spesso, questa attività viene risolta in questo modo: creano un file speciale application.propertiesche contiene tutte le informazioni necessarie e le includono nell'assieme. Puoi anche configurare lo script di compilazione in modo che i dati da questo file vengano migrati a MANIFEST.MFecc.

Ma la cosa più interessante è che Maven ha un plugin speciale che può generare un tale file application.properties. Per fare ciò, è necessario creare un tale file e riempirlo con modelli di dati speciali. Esempio:

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

I valori di tutti e tre i parametri verranno sostituiti in fase di compilazione.

I parametri pom.namee pom.versionsaranno presi direttamente da pom.xml. E per generare un numero di build univoco in Maven, esiste un plug-in speciale: buildnumber-maven-plugin. Vedi l'esempio qui sotto:

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

Nell'esempio sopra, accadono tre cose importanti. Innanzitutto, il plug-in stesso è specificato per l'impostazione della versione dell'assembly . In secondo luogo, viene specificato che verrà eseguito durante la fase di convalida (la primissima fase) e genererà un numero di build - ${buildNumber}.

E in terzo luogo, viene indicato il formato di questo numero di assieme, che è incollato insieme da più parti . Questa è la versione del progetto project.versione l'ora corrente fornita dal modello. Il formato del modello è specificato dalla classe Java MessageFormat.