Часть 4. основы maven

Деревья зависимостей

Одна из наиболее полезных функций Maven ― поддержка управления зависимостями: вы просто определяете библиотеки, от которых зависит ваше приложение, а Maven находит их (в локальном или центральном хранилище), загружает и использует для компиляции кода.

В некоторых случаях может потребоваться знание происхождения определенной зависимости — например, если в сборке оказались разные и несовместимые версии одного и того же JAR-файла. В этом случае нужно предотвратить включение в сборку одной версии JAR-файла, но сначала найти зависимости, удерживающие JAR.

Поиск зависимостей оказывается на удивление простым делом, если знать следующую команду:

mvn dependency:tree

Аргумент отображает все прямые зависимости, а затем показывает все подзависимости (а также их подзависимости и т.д.). Например, в листинге 5 приведен отрывок из клиентской библиотеки, требуемой одной из моих зависимостей.

Листинг 5. Дерево зависимостей Maven

 ------------------------------------------------------------------------
 Building Client library for communicating with the LDE
    task-segment: 
 ------------------------------------------------------------------------
 
 com.lmt.pos:sis-client:jar:2.1.14
 +- org.codehaus.woodstox:woodstox-core-lgpl:jar:4.0.7:compile
 |  \- org.codehaus.woodstox:stax2-api:jar:3.0.1:compile
 +- org.easymock:easymockclassextension:jar:2.5.2:test
 |  +- cglib:cglib-nodep:jar:2.2:test
 |  \- org.objenesis:objenesis:jar:1.2:test

Из видно, что проекту требуются библиотеки и . Библиотеке , в свою очередь, требуются библиотеки и . В случае возникновения проблем с , таких как наличие двух версий, 1.2 и 1.3, это дерево зависимостей показало бы, что артефакт 1.2 импортирован косвенным путем библиотекой .

Аргумент сэкономил мне много часов диагностики ошибочной сборки; надеюсь, что и для вас он сделает то же самое.

Заголовок

Внутри тэга project содержится основная и обязательная информация о проекте:

Пример 3. Заголовок

В Maven каждый проект идентифицируется парой groupId, artifactId.

Во избежание конфликта имён, groupId — наименование организации или подразделения и обычно действуют такие же правила как и при именовании пакетов в Java — записывают доменное имя организации или сайта проекта.

artifactId — название проекта.

Внутри тэга version хранится версия проекта.

Тройкой groupId, artifactId, version (далее — GAV) можно однозначно идентифицировать jar файл приложения или библиотеки. Если состояние кода для проекта не зафиксировано, то в конце к имени версии добавляется «-SNAPSHOT» что обозначает, что версия в разработке и результирующий jar файл может меняться.

Основные сведения

Мавен изначально создавался , принимая во внимание портируемость. Но довольно часто приложение приходится запускать в разном окружении: например, для разработки используется одна база данных, в рабочем сервере используется другая. при этом могут понадобиться разные настройки, разные зависимости и плагины. Для этих целей в maven используются профайлы.

Давайте определим два профайла: один для разработки, другой для производственного сервера. Для разработки вполне подойдёт база hsqldb, которая хранит все данные в памяти. На производственном сервере же используется база данных postgres, которая сохраняет все данные на диск. В профайлах для каждой конфигурации определены свои проперти database.url и зависимости для разных jdbc драйверов.

Ниже приведён пример объявления таких профайлов.

<?xml version="1.0" encoding="UTF-8"?>
<project>
  <profiles>
(1)     <profile>
            <id>development</id>
            <properties>
                <database.url>jdbc:hsqldb:mem:testdb</database.url>
            </properties>
            <dependencies>
                <dependency>
                    <groupId>org.hsqldb</groupId>
                    <artifactId>hsqldb</artifactId>
                    <version>2.0.0</version>
                </dependency>
            </dependencies>
        </profile>
(2)     <profile>
            <id>productionServer</id>
            <properties>
                <database.url>jdbc:postgresql://databseserver/database</database.url>
            </properties>
            <dependencies>
                <dependency>
                    <groupId>postgresql</groupId>
                    <artifactId>postgresql</artifactId>
                    <version>9.0-801.jdbc4</version>
                </dependency>
            </dependencies>
        </profile>
    </profiles>
    .....
</project>
               

цифрами 1 и 2 обозначены начала объявления профайлов. каждый профайл имеет идентификатор в данном случае development и productionServer.

Внутри тэга <profile> содержатся все те же объявления что и внутри <project>: properties, dependencies, и др. Вот полный список тегов которые могут содержаться внутри профайлов:

Объявление зависимостей

Простой «Hello World» пример полностью автономный и не зависит от каких-либо дополнительных библиотек. Однако, большинство приложений зависит от внешних библиотек, с реализацией распостраненного и/или сложного функционала.

К примеру, предположим, что в дополнение к «Hello World!» вы хотите, чтобы приложение печатало текущую дату и время. Вы могли бы использовать функциональность из стандартных(native) Java библиотек, но мы можем сделать это и другими интересными способами, например с помощью Joda Time библиотеки.

Для начала, изменим , как показано ниже:

Здесь использует Joda Time класс для получения и печати текущего времени.

Если бы вы запустили для сборки проекта сейчас, то получили бы ошибку сборки, потому что вы не объявили Joda Time компилируемую зависимость в сборке. Вы можете это исправить, добавив следующие строки в pom.xml(в пределах элемента):

Этот блок XML объявляет список зависимостей проекта. В частности, он объявляет единственную зависимость от Joda Time библиотеки. В элементе, зависимость определяется через описание трех вложенных элементов:

• — группа или организация, к которой принадлежит зависимость.
• — необходимая библиотека
• — версия необходимой библиотеки

По умолчанию, все зависимости определены как зависимости. Т.е. они должны быть доступны во время компиляции(а если вы собираете WAR-файл, то в /WEB-INF/lib каталоге). Кроме того, вы можете добавить элемент, с одним из значений:

• — зависимости, которые требуются для компиляции кода проекта, но которые будут доступны во время выполнения кода контейнером(например, Java Servlet API)
• — зависимости, которые используются для компиляции и запуска тестов, но не требуемые для сборки или выполнения кода проекта

Сейчас, если вы выполните или , Maven должен будет разрешить Joda Time зависимость из Maven Central репозитория и успешно собрать проект.

Здесь полная версия :

Developers

Project Plugin Management

Использование профилей

Наиболее значительные проекты содержат, по крайней мере, базовую группу инструментальных сред, решающих задачи, связанные с разработкой, контролем качества (QA), интеграцией и производством. Задача управления всеми этими средами заключается в настройке сборки, которая должна подключаться к нужной базе данных, выполнять нужный набор сценариев и развертывать в каждой среде все необходимые артефакты. С помощью профилей Maven можно делать все это без необходимости составлять четкие инструкции для каждой среды индивидуально.

Ключом служит объединение профилей всех систем с проблемно-ориентированными профилями. Каждый профиль системы определяет конкретные места, сценарии и серверы. Так, в своем файле pom.xml я определяю проблемно-ориентированный профиль , как показано в листинге 6.

Листинг 6. Профиль развертывания

    <profiles>
        <profile>
            <id>deploywar</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>net.fpic</groupId>
                        <artifactId>tomcat-deployer-plugin</artifactId>
                        <version>1.0-SNAPSHOT</version>
                        <executions>
                            <execution>
                                <id>pos</id>
                                <phase>install</phase>
                                <goals>
                                    <goal>deploy</goal>
                                </goals>
                                <configuration>
                                    <host>${deploymentManagerRestHost}</host>
                                    <port>${deploymentManagerRestPort}</port>
                                    <username>${deploymentManagerRestUsername}</username>
                                    <password>${deploymentManagerRestPassword}</password>
                                    <artifactSource>
                                      address/target/addressservice.war
                                    </artifactSource>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

Этот профиль, определяемый идентификатором , выполняет плагин , настроенный на подключение к определенному узлу, порту и к определенным учетным данным (имя пользователя/пароль). Вся эта информация задается с помощью переменных, таких как . Эти переменные определены в моем файле profiles.xml для каждой инструментальной среды, как показано в листинге 7.

Листинг 7. profiles.XML

        <!-- Defines the development deployment information -->
        <profile>
            <id>dev</id>
            <activation>
                <property>
                    <name>env</name>
                    <value>dev</value>
                </property>
            </activation>
            <properties>
                <deploymentManagerRestHost>10.50.50.52</deploymentManagerRestHost>
                <deploymentManagerRestPort>58090</deploymentManagerRestPort>
                <deploymentManagerRestUsername>myusername</deploymentManagerRestUsername>
                <deploymentManagerRestPassword>mypassword</deploymentManagerRestPassword>
            </properties>
        </profile>

        <!-- Defines the QA deployment information -->
        <profile>
            <id>qa</id>
            <activation>
                <property>
                    <name>env</name>
                    <value>qa</value>
                </property>
            </activation>
            <properties>
                <deploymentManagerRestHost>10.50.50.50</deploymentManagerRestHost>
                <deploymentManagerRestPort>58090</deploymentManagerRestPort>
                <deploymentManagerRestUsername>
                  myotherusername
                </deploymentManagerRestUsername>
                <deploymentManagerRestPassword>
                  myotherpassword
                </deploymentManagerRestPassword>
            </properties>
        </profile>

Развертывание профилей Maven

В файле profiles.xml в я определил два профиля и активизировал их на основе значения свойства (среды) . Если свойству присвоить значение , то будет использоваться информация для развертывания среды разработки. Если свойству присвоить значение , то будет использоваться информация для развертывания среды QA, и т.д.

Вот команда для развертывания файла:

mvn -Pdeploywar -Denv=dev clean install

Флаг предписывает Maven явно включить профиль . Оператор создает системное свойство с именем и присваивает ему значение , которое активирует конфигурацию среды разработки. Передача активировала бы конфигурацию среды QA.

История разработки

Maven был создан канадцем Джейсоном ван Зилом (Jason van Zyl) и организованной им фирмой Sonatype. Он начался как подпроект Apache Turbine в 2002 г. В 2003 году Maven был квалифицирован как Apache-проект верхнего уровня, тогда же появилась его первая версия — Maven 1.x. Она была опубликована 13 июля 2004 как версия 1.0. Это происходило, однако, так быстро, что некоторые частности оказались непродуманными. Например, слишком много конфигурации, проблемы с производительностью.

Поэтому концепция была доработана и с 2005 года началась параллельная разработка Maven 2.x, которая была сдана в версии 2.0 19 октября 2005 года.

Maven 1.x не разрабатывается дальше и ограничивается поддержкой пользователей и устранением ошибок.

Разработка Maven 3.0 началась в 2008 г.. После восьми альфа-релизов, первая бета-версия Maven 3.0 была опубликована в октябре 2010 г

Особенное внимание было уделено её обратной совместимости с Maven 2. Для большинства проектов переход от версии Maven 2 к версии Maven 3 не требует никаких изменений.

Разработка Maven происходит в следующих подпроектах:

• Maven 1.x и Maven 2.x — старые версии Maven-а.
• Maven 3.x развивает текущую линию продуктов Maven.
• Plugins разрабатывает большинство Maven-плагинов.
• Shared Components изготовляет компоненты программного обеспечения, которые могут использоваться всеми другими подпроектами.
• Ant Tasks позволяет использовать возможности Ant из Maven.
• Doxia — это фреймворк для генерации контента из форматов Almost Plain Text (APT), Confluence, DocBook, FML (FAQ Markup Language), LaTeX, Rich Text Format (RTF), TWiki, XDoc и XHTML.
• SCM (Source Code Management) разрабатывает программное обеспечение для подключения Apache к различным системам версионирования как CVS или Subversion.
• Surefire разрабатывает тест-фреймворк для Maven-а.
• Wagon готовит абстракцию коммуникационных протоколов как «доступ к файлам», HTTP или FTP.

Developers

Developers

С этим читают

• Jar-файлы в windows
• Apache
• Postcss-loader
• Long time no see
• 15 лучших бесплатных vst плагинов 2019 года
• 9 wordpress плагин для создания зоны членов
• Java swing tutorial: examples to create gui
• 20 шорткодов и плагинов wordpress, которые вы возможно захотите попробовать
• Php на windows и iis7
• Установка сервера в связке: apache 2, php 5 и mysql 5