Speciális Maven projekt felépítés

1.1 A Mavenben építendő beépülő modulok listája

A Maven összeállítása nagyon rugalmasan konfigurálható. A Maven fejlesztői speciálisan több tucat plugint készítettek, amelyek segítségével nagyon rugalmasan konfigurálhatja a különféle buildeket. Ezek közül a legnépszerűbbek az alábbi táblázatban láthatók:

Mindegyik bővítmény érdekes a maga módján, de mindegyiket elemeznünk kell. Kezdjük a fő dologgal - a fordításkezelő bővítménnyel.

1.2 Fordítási bővítmény maven-compiler-plugin

A legnépszerűbb plugin, amely lehetővé teszi a fordító verziójának vezérlését, és szinte minden projektben használatos, a maven-compiler-plugin. Alapbeállításai vannak, de szinte minden projektben újra be kell őket állítani.

A legegyszerűbb verzióban a beépülő modulban meg kell adnia a Java forráskód verzióját és annak a Java gépnek a verzióját, amelyen az összeállítás történik:

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

A fenti példában három Java-fordító beállítást adtunk meg: source, targetés encoding.

A paraméter sourcelehetővé teszi, hogy beállítsuk forrásaink Java verzióját. A paraméter targeta Java gép azon verziója, amely alatt az osztályokat le szeretné fordítani. Ha nincs megadva kód vagy Java gépverzió, akkor az alapértelmezett 1.3

Végül a paraméter encodinglehetővé teszi a Java fájlok kódolásának megadását. jeleztük UTF-8. Mostanra szinte minden forrás a következőben van tárolva UTF-8. De ha ez a paraméter nincs megadva, akkor az operációs rendszer aktuális kódolása kerül kiválasztásra. Windows esetén ez a kódolás Windows-1251.

Vannak olyan esetek is, amikor a felépített számítógépen a Java több verziója is telepítve van: különböző modulok és/vagy projektek készítéséhez. Ebben az esetben JAVA_HOMEcsak az egyik elérési útja adható meg a változóban.

Ezen kívül a Java gépnek különböző megvalósításai vannak: OpenJDK, OracleJDK, Amazon JDK. És minél nagyobb a projekt, annál bonyolultabb a felépítése. De a címke használatával kifejezetten beállíthatja a bővítmény javac fordítójának elérési útját . Kifejezetten erre az alkalomra adták hozzá.

A bővítménynek maven-compiler-pluginkét célja van:

• compiler:compile– források összeállítása, alapértelmezés szerint a fordítási fázishoz társítva
• compiler:testCompile– tesztek összeállítása, alapértelmezés szerint a teszt-összeállítási fázishoz kapcsolódik.

A parancssorban megadhatja a javac fordítónak átadandó argumentumok listáját is:

<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 jar fájl létrehozásához maven-jar-plugin

Ha saját jar könyvtárat szeretne felépíteni a Maven segítségével, szüksége lesz a maven-jar-pluginre. Ez a bővítmény sok hasznos dolgot végez.

Példa egy ilyen bővítményre:

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

Először is megadhatja, hogy mely fájlok kerüljenek a könyvtárba, és melyek nem. <include>A szakaszban található címkék segítségével <includes>megadhatja azon könyvtárak listáját, amelyek tartalmát hozzá kell adni a könyvtárhoz .

Másodszor, minden jarnak rendelkeznie kell egy manifeszttel ( MANIFEST.MF fájl ). Maga a beépülő modul a megfelelő helyre teszi a könyvtárban, csak meg kell adni, hogy melyik útvonalon haladjon tovább. A címkét erre használják <manifestFile>.

Végül a beépülő modul önmagában is létrehozhat egy manifestet. Ehhez a címke helyett <manifestFile>egy címkét kell hozzáadnia , <manifest>és meg kell adnia benne a jövőbeli jegyzék adatait. Példa:

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

A címke <addClasspath>határozza meg, hogy hozzá kell-e adni a jegyzékhez CLASSPATH.

A címke <classpathPrefix>lehetővé teszi egy előtag hozzáadását (a lib példában) minden erőforrás elé. Az előtag megadása <classpathPrefix>lehetővé teszi a függőségek külön mappába helyezését.

Igen, elhelyezhet könyvtárakat egy másik könyvtáron belül. És sok meglepetés vár rád, amikor valahol át kell adnod a tulajdonságfájl elérési útját, ami a jar könyvtárban van, ami a jar könyvtárban van.

Végül a címke <mainClass>a fő végrehajtható osztályra mutat. „Mi a fő végrehajtható osztály? ", - kérdezed. És a helyzet az, hogy egy Java gép olyan programot futtathat, amelyet nem csak egy Java osztály, hanem egy jar fájl is megad. És erre az esetre van szükség a fő induló osztályra.

1.4 Build number generation plugin buildnumber-maven-plugin

A jar könyvtárak és a háborús fájlok nagyon gyakran tartalmaznak információkat a projekt nevével és verziójával, valamint az összeállítás verziójával. Ez nem csak a függőségek kezeléséhez hasznos, de a tesztelést is leegyszerűsíti: egyértelmű, hogy a könyvtár melyik verziójában javították ki a hibát, és melyikhez adták hozzá.

Leggyakrabban ezt a feladatot így oldják meg - létrehoznak egy speciális fájlt, application.propertiesamely tartalmazza az összes szükséges információt, és belefoglalja az összeállításba. A build szkriptet úgy is beállíthatja, hogy az ebből a fájlból származó adatok áttelepüljenek a MANIFEST.MFstb.

De ami a legérdekesebb, az az, hogy a Mavennek van egy speciális bővítménye, amely képes létrehozni egy ilyen application.properties fájlt. Ehhez létre kell hoznia egy ilyen fájlt, és speciális adatsablonokkal kell kitöltenie. Példa:

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

Mindhárom paraméter értéke az építési szakaszban lecserélődik.

pom.nameA és paraméterek pom.versionközvetlenül innen származnak pom.xml. Egyedi buildszám generálásához pedig a Mavenben van egy speciális plugin - buildnumber-maven-plugin. Lásd az alábbi példát:

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

A fenti példában három fontos dolog történik. Először is maga a bővítmény van megadva az összeállítás verziójának beállításához . Másodszor meg van adva, hogy az érvényesítési fázisban (a legelső fázisban) futni fog, és létrehoz egy buildszámot - ${buildNumber}.

Harmadszor pedig fel van tüntetve ennek az összeállítási számnak a formátuma, amely több részből van összeragasztva . Ez a projekt verziója project.versionés a sablon által megadott aktuális idő. A sablon formátumát a Java osztály határozza meg MessageFormat.