1.1 Списък с добавки за изграждане в Maven
Сглобяването в Maven може да бъде конфигурирано много гъвкаво. Разработчиците на Maven са създали специално десетки добавки, с помощта на които можете много гъвкаво да конфигурирате различни компилации. Най-популярните от тях са показани в tableта по-долу:
плъгин | Описание | |
---|---|---|
1 | maven-компилатор-плъгин | Управлява Java компилация |
2 | плъгин за maven-ресурси | Контролира включването на ресурси в сборка |
3 | плъгин за източник на maven | Контролира дали изходният code е включен в сборка |
4 | maven-dependency-plugin | Контролира процеса на копиране на библиотеки със зависимости |
5 | maven-jar-plugin | Плъгин за създаване на финален jar файл |
6 | плъгин за maven war | Плъгин за създаване на окончателния военен файл |
7 | maven-surefire-плъгин | Управлява тестови изпълнения |
8 | buildnumber-maven-plugin | Генерира номер на компилация |
Всеки плъгин е интересен по свой начин, но ще трябва да ги анализираме всички. Да започнем с основното - плъгина за управление на компилация.
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
.
GO TO FULL VERSION