Разширено изграждане на проект Maven

1.1 Списък с добавки за изграждане в Maven

Сглобяването в Maven може да бъде конфигурирано много гъвкаво. Разработчиците на Maven са създали специално десетки добавки, с помощта на които можете много гъвкаво да конфигурирате различни компилации. Най-популярните от тях са показани в tableта по-долу:

Всеки плъгин е интересен по свой начин, но ще трябва да ги анализираме всички. Да започнем с основното - плъгина за управление на компилация.

1.2 Приставка за компorране maven-compiler-plugin

Най-популярният плъгин, който ви позволява да контролирате versionта на компилатора и се използва в почти всички проекти, е maven-compiler-plugin. Има настройки по подразбиране, но в почти всеки проект те трябва да бъдат зададени отново.

В най-простата version, в приставката, трябва да посочите versionта на изходния code на Java и versionта на Java машината, под която се извършва сглобяването:

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

В горния пример задаваме три опции за компилатор на Java source: targetи encoding.

Параметърът sourceни позволява да зададем versionта на Java за нашите източници. Параметърът targetе versionта на Java машината, под която искате да компorрате класовете. Ако не е указан code or version на Java машина, тогава по подразбиране е 1.3

И накрая, параметърът encodingви позволява да посочите codeирането на Java файловете. Ние посочихме UTF-8. Сега почти всички източници се съхраняват в UTF-8. Но ако този параметър не е посочен, тогава ще бъде избрано текущото codeиране на операционната система. За Windows това е codeирането Windows-1251.

Има и случаи, когато компютърът за изграждане има инсталирани няколко версии на Java: за изграждане на различни модули и/or различни проекти. В този случай JAVA_HOMEв променливата може да бъде указан само пътят до един от тях.

Освен това има различни реализации на Java машината: OpenJDK, OracleJDK, Amazon JDK. И колкото по-голям е проектът, толкова по-сложна е неговата структура. Но можете изрично да зададете пътя до компилатора на javac за плъгина, като използвате маркера . Добавен е специално за този повод.

Плъгинът maven-compiler-pluginима две цели:

• compiler:compile– компorране на източници, по подразбиране свързани с фазата на компorране
• compiler:testCompile– компилация на тестове, по подразбиране е свързана с фазата тест-компorране.

Можете също да посочите списък с аргументи, които да бъдат предадени на компилатора на javac в командния ред:

<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 Добавка за създаване на jar файл maven-jar-plugin

Ако искате да създадете своя собствена библиотека от буркани с Maven, ще ви трябва добавката maven-jar. Този плъгин прави много полезни неща.

Пример за такъв плъгин:

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

Първо, може да се използва за указване кои файлове ще влязат в библиотеката и кои не. Използвайки тагове <include>в секцията, <includes>можете да посочите списък с директории, чието съдържание трябва да се добави към библиотеката .

Второ, всеки буркан трябва да има манифест ( файл MANIFEST.MF ). Плъгинът сам ще го постави на правилното място в библиотеката, само трябва да посочите по кой път да го поемете. За това се използва етикетът <manifestFile>.

И накрая, плъгинът може сам да генерира манифест. За да направите това, instead of таг, <manifestFile>трябва да добавите таг <manifest>и да посочите в него данни за бъдещия манифест. Пример:

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

Етикетът <addClasspath>указва дали да се добави към манифеста CLASSPATH.

Тагът <classpathPrefix>ви позволява да добавите префикс (в примерната библиотека) преди всеки ресурс. Посочването на префикс в <classpathPrefix>ви позволява да поставите зависимости в отделна папка.

Да, можете да поставите библиотеки в друга библиотека. И има много изненади, които ви очакват, когато трябва да прехвърлите някъде пътя до file със свойства, който е в библиотеката на буркани, който е в библиотеката на буркани.

И накрая, тагът <mainClass>сочи към главния изпълним клас. „Какъв е главният изпълним клас? ", - ти питаш. Работата е там, че Java машина може да изпълнява програма, която е определена не само от Java клас, но и от jar файл. И именно за този случай е необходим основният начален клас.

1.4 Плъгин за генериране на номера на компилация buildnumber-maven-plugin

Много често jar библиотеките и военните файлове включват информация с името на проекта и неговата version, Howто и versionта на сборката. Това не само е полезно за управление на зависимостите, но също така опростява тестването: ясно е в коя version на библиотеката е коригирана грешката и в коя е добавена.

Най-често тази задача се решава по следния начин - те създават специален файл application.properties, който съдържа цялата необходима информация и го включва в монтажа. Можете също така да конфигурирате скрипта за изграждане, така че данните от този файл да мигрират към MANIFEST.MFи т.н.

Но най-интересното е, че Maven има специален плъгин, който може да генерира такъв файл application.properties. За да направите това, трябва да създадете такъв файл и да го попълните със специални шаблони за данни. Пример:

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

Стойностите и на трите параметъра ще бъдат заменени на етапа на изграждане.

Параметрите pom.nameи pom.versionще бъдат взети директно от pom.xml. А за генериране на уникален номер на компилация в Maven има специален плъгин - buildnumber-maven-plugin. Вижте примера по-долу:

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

В горния пример се случват три важни неща. Първо, самият плъгин е указан за настройка на versionта на асемблиране . Второ, уточнено е, че ще работи по време на фазата на валидиране (първата фаза) и ще генерира номер на компилация - ${buildNumber}.

И трето, посочва се форматът на този номер на сглобяване, който е залепен заедно от няколко части . Това е versionта на проекта project.versionи текущото време, дадени от шаблона. Форматът на шаблона се определя от Java класа MessageFormat.