Наводим порядок в разработке ПО вместе с maven. Часть 2
Я продолжаю рассказ об maven – инструменте управления проектом, составляющими его модулями, зависимостями модулей от различных библиотек-артефактов и многим другим. Maven имеет несколько “лиц” или областей применения, которые будут раскрываться перед вами по мере изучения maven, плагинов для maven и смежных инструментов.
Сегодня я продолжаю рассказ о начатом в прошлой статье примере создания проекта maven, его настройки. Так, разобравшись с основными параметрами проекта (название, описание, список авторов), самое время перейти к описанию зависимостей и тому, как инициировать различные события из жизненного цикла проекта.
Напомню, что рассматриваемый проект maven состоял из трех классов: HelloBean, HelloMaven, TestHelloBean. Первый из них - HelloBean – это класс, реализующий бизнес-логику приложения (не слишком сложную: вывод на экран фразы “hello world”). Затем идет класс HelloMaven, состоящий только из одного метода main, в котором демонстрировалось создание объекта HelloBean и вызов методов “сказать_привет”. В полном соответствии с правилом “код, для которого нет тестов и который нельзя проверить, просто не существует” я создал и третий класс примера - TestHelloBean. Он является наследником стандартного для junit 3 класса TestCase. Возникает естественный вопрос: откуда maven узнает о месторасположении junit3 библиотеки, и как нужно указать к ней путь при запуске javac (компиляции проекта) или запуске самого теста? Все это происходит благодаря “магии” maven dependencies. В файле pom я перечисляю то, какие библиотеки нужны для работы проекта:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.2</version>
<scope>test</scope>
</dependency>
</dependencies>
Количество зависимостей “dependency”, которые вы можете объявить внутри элемента “dependencies” не ограничено, и каждая из зависимостей состоит из обязательных элементов groupId, artifactId, version. Теперь попробуем скомпилировать проект и запустить его на выполнение. Для этого в каталоге проекта я выполняю команду “m2 compile”. В результате на экране появится множество сообщений вида:
[INFO] Scanning for projects...
[INFO] ------------------------------------
[INFO] Building Simple Maven 2 Artifact
[INFO] task-segment: [compile]
[INFO] ------------------------------------
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.2/maven-resources-plugin-2.2.pom
Если у вас не активно подключение к internet, то запуск maven-а завершится неудачей с сообщением, что maven не может загрузить нужные для своей работы артефакты:
[INFO] Failed to resolve artifact.
GroupId: org.apache.maven.plugins
ArtifactId: maven-resources-plugin
Version: 2.2
Reason: Unable to download the artifact from any repository
org.apache.maven.plugins:maven-resources-plugin:pom:2.2
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
Вспомните, когда вы загружали из internet архив с дистрибутивом maven, разве вас не удивил его маленький размер (всего пара мегабайт). На самом деле дистрибутив maven-а содержит только его ядро, а для любого действия (даже такого примитивного как компиляция) нужны плагины. И эти плагины загружаются из internet, из репозитория расположенного по адресу
http://repo1.maven.org/maven2. Например, maven решил загрузить плагин maven-resources-plugin только для того, чтобы обработать файлы, расположенные в каталоге resources. Для того, чтобы выполнить компиляцию нужен плагин maven-compiler-plugin, и так далее. Значит, вам нужно включить internet и запустить команду “m2 compile” еще раз. После некоторого ожидания (пока нужные плагины загрузятся из сети) maven скомпилирует исходные коды проекта и поместит их в новый каталог target (размещен в корне каталога с проектом). Помимо компилированных *.class файлов, в каталог target будут помещены также все файлы, которые были найдены в каталоге “src/main/resources”. Например, если я использую в своем проекте библиотеку log4j для того, чтобы выводить на экран или в файл отладочные сообщения по ходу работы приложения, то файл log4j.properties нужно размещать, именно, внутри каталога “src/main/resources”. Редактируя java-код в вашей любимой IDE и компилируя его с помощью “m2 compile” можно организовать простенький цикл разработки, но … В практике никто не выполняет запуск только команды compile, т.к. она не выполняет синхронизацию каталога target с содержимым каталога src. К примеру, если в первоначальной версии проекта у вас был класс Apple, и вы его скомпилировали и разместили внутри target,то после того как Apple был удален из каталога “src/main/java”, то в каталоге “target/classes” он все равно будет присутствовать. Поэтому нужно каталог target каждый раз перед компиляцией очищать. И делать это нужно не “руками”, а возложить на maven: maven умеет принимать и обрабатывать сразу несколько команд, например: “m2 clean compile”. Нужные для работы maven библиотеки-плагины загружаются из internet только один раз и сохраняются в локальном репозитории. Если вы работаете на windows xp, то в каталоге с настройками вашей учетной записи "C:\Documents and Settings\MyAccountUserName\" появится подкаталог .m2, в котором maven будет хранить все нужные своей работы артефакты и файлы настроек. Артефакты размещаются внутри подкаталога repository, а файл настроек settings.xml размещен в корне каталога “.m2” (изначально файла с настройками может и не быть). Давайте попробуем найти в репозитории библиотеку junit. Из названия артефакта мы можем предположить, что файл jar должен быть размещен в подкаталоге junit, каталога repository. Однако, ничего подобного в репозитории нет. Почему, ведь разве мы не сказали, что проекту нужна библиотека junit? Не совсем: я не только указал, что мне нужна junit, но и определил область действия библиотеки “
test”. Т.е. запуск команды compile не приводит к компиляции файлов размещенных в каталоге “src/test/java” и, соответственно, загрузке для них нужных артефактов-библиотек. Давайте, выполним команду “m2 test”. Только в этом случае maven начнет загружать библиотеку junit из internet (ого, кроме junit потянулись еще и еще библиотеки: какая-то surefire и многое другое). А еще на экране появится сообщение:
------------------------
T E S T S
------------------------
Running blackzorro.TestHelloBean
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
Как видите, maven не только скомпилировал файлы в каталоге src/test/java (результаты компиляции были помещены в каталог target/test-classes), но еще и запустил тесты на выполнение (один единственный junit тест завершился удачно). Отчеты о запуске тестов были представлены в виде xml и txt файлов, размещенных в каталоге “target/surefire-reports” (вот зачем был нужен плагин surefire). Теперь вернемся в каталог “C:\Documents and Settings\MyAccountUserName\.m2\repository" и снова попробуем найти там подкаталог junit. Теперь каталог мы найдем, но очень важно то, что сама jar-библиотека junit.jar не размещена сразу внутри каталога junit. Вместо этого maven создал подкаталог “junit/3.8.2” и уже внутри которого поместил jar-файл библиотеки junit-3.8.2.jar и еще какие-то, пока непонятные, файлы junit-3.8.2.jar.sha1, junit-3.8.2.pom, junit-3.8.2.pom.sha1 (о них позже). Подобная стратегия хранения артефактов наводит на мысль, что maven может одновременно хранить в своем локальном репозитории библиотеки различных версий и переключение между ними в вашем проекте может быть сведено к тривиальной смене цифры внутри тега “
” для зависимости “”. Давайте, попробуем сменить версию junit с давным-давно устаревшего “3.8” на “4.4”. Я исправил файл pom.xml, также я подправил исходный код
класса TestHelloBean:
public class TestHelloBean { @Test
public void testSimpleMessage() { String message = new HelloBean("Maven 2").sayHello(); Assert.assertEquals("Test Hello Machine", "Hello, Maven 2", message); }
}
c:\testartifact1\src\test\java\blackzorro\TestHelloBean.java:[9,5] annotations are not supported in -source 1.3
(try -source 1.5 to enable annotations)
@Test
m2 test -Dmaven.compiler.source=1.5 -Dmaven.compiler.target=1.5
... и ответ maven ...
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<verbose>true</verbose>
<executable>E:/Program_Files_2/jrockit_150_11/bin/javac.exe</executable>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>имя-плагина</artifactId>
<executions>
<execution>
<id>myCustomTask</id>
<phase>generate-sources</phase>
<goals>
<goal>PluginGoal</goal>
</goals>
... и настройки плагина …
После того как мы научились компилировать и тестировать проект самое время его запустить. Maven предоставляет очень мощные средства по созданию среды выполнения приложения. И если в случае простых java desktop приложений все эти действия сводятся к вызову плагина “exec:java”, с указанием имени запускаемого java класса в системном свойства “exec.mainClass”, как показано в следующем примере:
mvn exec:java -Dexec.mainClass=package.ClassName