Зачем ?
Много раз я пытался решить несколько основных или сложных проблем со структурой проекта Maven / Java EE в своей повседневной работе. Чтобы предоставить решения, я часто в конечном итоге экспериментирую со структурой проекта, тестирую свое развертывание на разных серверах приложений и детализирую свою конфигурацию.
У Maven может быть крутая кривая обучения для новичков, и если вы добавите в сочетание « иногда » сложные требования к конфигурации современного приложения Java EE , все станет еще сложнее. Я также видел в своей карьере, что многие начинающие Java-разработчики , когда они присоединяются к большой команде или проекту, в большинстве случаев структура проекта уже детально проработана и настроена для них более старшими членами. Они предполагают, что это работает, и они не потратили время, чтобы понять проводку и конфигурацию. Я сделал эту ошибку сам в прошлом. Им поручают простые задачи кодирования, и они глубоко погружаются в требования, но, к сожалению, они забывают изучить структуру приложения. Их старшие коллеги также забывают обучать их в этой конкретной области, в большинстве случаев из-за временных ограничений. Это может привести к несчастным случаям, когда люди начинают бездельничать со структурой приложения без предыдущего опыта, пытаясь « заставить его работать» . Maven и его соглашения нацелены на то, чтобы помочь в создании общих структур и соглашений о том, как проект должен быть структурирован, но опять же вам нужно понять инструмент соглашения и затем освоить вашу « конфигурацию ».
Часто можно услышать, как кто-то говорит: « Я добавил эту библиотеку туда, и она сработала », если вы ответите « определите там », то вы можете получить некоторые интересные ответы. Иногда по случайности или по счастливой случайности это работает, но в сложном многомодульном приложении, в большинстве случаев « это просто работает », является преуменьшением, и проблемы начнут появляться достаточно скоро.
Эта серия публикаций в основном предназначена для новичков в Maven и Java EE , но вы можете поделиться ими или использовать их в качестве демонстрационной версии, если вы являетесь более опытным разработчиком. Я собираюсь «атаковать» на демонстрационной основе некоторые реальные проблемы, с которыми я сталкиваюсь, обнаруживая изо дня в день работу, и пытаюсь найти решения, предоставляя базовое объяснение или ссылки на соответствующие ресурсы. Пожалуйста, не стесняйтесь добавлять комментарии, исправления или ссылки для чего-то, что может быть выполнено / завершено намного чище. Лучший способ изучить Maven и создать «сложное», но простое в обслуживании приложение — это начать с нуля, пустые файлы pom.
Главное сообщение, которое я пытаюсь передать начинающим разработчикам, читающим мои посты, заключается в том, что « изучение» структуры вашего приложения, расспрос о базовых инструментах сборки — это часть вашей работы, и вы никогда не должны предполагать, что кто-то другой всегда будет заботиться о вас. это Это также шаг, чтобы бросить вызов более сложным задачам и улучшить свои навыки разработчика Java.
Основные технологии, которые будут использоваться
- Приложение на основе Java EE 7
- Будет упакован как EAR
- Будут представлены несколько компонентов (войны, банки, ejb банки)
- Будет скомпилировано в сторону Java 7
- Будет упакован с использованием Maven 3
Мое приложение для демонстрации ушей
Мое приложение должно быть EAR , для этого конкретного поста это ухо будет включать 2 модуля верхнего уровня — войну и ejb-jar. Также будет фляга, которая будет содержать классы, которые будут моей моделью домена базы данных (сущности JPA). Я собираюсь расширить структуру, добавив больше ресурсов в будущих постах. Очень абстрактный образ, просто чтобы дать идею, иллюстрирующую то, что собирается «включить в наше ухо». Военный модуль в будущем будет содержать сервлеты или JSF-компоненты, а сервисный модуль будет содержать набор общих компонентов Sesson Beans без состояния (или компонентов, управляемых сообщениями). Доменный проект будет иметь простые Java-классы, должным образом аннотированные конструкциями JPA 2.
Составление базовой структуры нашего приложения с использованием Maven
Чтобы построить слух, нам нужно определить модули и части нашего приложения, используя Maven, который в любом случае является нашим инструментом построения / упаковки / конфигурации. Это один из самых важных шагов, и если вы получите это с самого начала, то остальными будут простые технические детали или особенности конфигурации. То, что я предлагаю, — это не окончательное решение, а нечто очень близкое к стандарту, которое в большинстве случаев является «подходом», если вы запускаете новое приложение, поэтому здесь нет особых деталей, давайте следовать стандарту и начнем строить на бетонное основание.
Итак, давайте на данный момент забудем изображение, приведенное выше, и давайте подумаем, Maven, что и сколько модулей могут определять, как их соединять и определять зависимости. Обратите внимание, что предлагаемый мной способ работы является стандартным, но он не является окончательным решением. Это означает, что вы можете достичь тех же результатов, упаковав свое приложение в ухо, определив меньшее количество модулей и зависимостей. Давайте предположим, что я хочу охватить очень сложные структуры, поэтому я определю общую структуру, всегда следуя стандартам.
Я предполагаю, что вы рассмотрели некоторые основные вещи из Maven, и вы, по крайней мере, знакомы с терминологией. Если нет, посмотрите здесь .
Помните, что Maven — это размещение ваших файлов в нужных местах в соответствии с четко определенной структурой и определение плагинов maven, которые представляют собой инструменты для компиляции, упаковки, копирования файлов и т. Д. Плагины вызываются Maven, так что да, вам снова нужно определить плагины в правильном месте и с соответствующей конфигурацией. Вы не пишете свои скрипты make или ant, вы просто «вставляете» плагины и просите maven выполнить их в четко определенном порядке.
Как мой хороший бывший коллега (недавно написал в электронном письме), хорошо нарушать соглашения в вашей жизни и в вашем кодировании, но никогда с Maven . Он прав!
Если вы не уверены, как установить Maven, посмотрите здесь Windows или Mac
Структура моего проекта Maven — Аннотация
Мы строим с Maven, поэтому мы должны думать о терминах и модулях maven. Для того, чтобы создать необходимую упаковку для ушей (см. Выше), нам нужно 5 poms
- Пом — действующий как родитель
- Пом, который будет содержать / определять последнее ухо — отвечает за настройку окончательного пакета.
- Пом, который будет содержать / определять код веб-приложения, то есть наш .war
- Пом, который будет содержать / определять код ejb-модуля, модуля, в который мы собираемся упаковать наши EJB-компоненты
- Пом, который будет содержать классы, которые будут нашими JPA (объектами базы данных)
Как видите, у каждого модуля есть свой pom, и есть родитель, одна из вещей, которую многие люди не добавляют в свою структуру, предполагая, что им это не нужно, так как их проект небольшой, и через некоторое время, когда добавляются другие модули, вы в конечном итоге получите хаос. Так что запишите здесь: «Родительский pom действительно хорошо иметь и настраивать ». Это pom, в котором вы определяете все свои версии зависимостей (то есть библиотеки) и настраиваете подключаемые модули maven, чтобы все дочерние poms наследовали общую конфигурацию.
Структура моего проекта Maven — родительский помп
Как я уже говорил, мы начнем с нуля, поэтому я создаю новую папку с именем sample-parent и в эту папку добавляю новый файл pom.xml .
|
01
02
03
04
05
06
07
08
09
10
|
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <modelVersion>4.0.0</modelVersion> <groupId>gr.javapapo</groupId> <artifactId>sample-parent</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>pom</packaging> </project> |
Да, не взволнован, просто запишите элемент упаковки, который определяет « pom ». Родитель называется parent, потому что он «определяет» и управляет дочерними модулями, это делается в разделе определения модулей. Наш оригинальный пом становится чем-то вроде этого. Это означает, что мы должны создать соответствующие папки под нашим образцом-родителем , а затем добавить pom.xml к каждой из них.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
|
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <modelVersion>4.0.0</modelVersion> <groupId>gr.javapapo</groupId> <artifactId>sample-parent</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>pom</packaging> <modules> <module>sample-ear</module> <module>sample-web</module> <module>sample-services</module> <module>sample-domain</module> </modules> </project> |
Давайте продолжим добавлять еще несколько настроек …
Это важный раздел, так как мы определяем версии для
- плагины Maven мы будем использовать и настраивать
- любые библиотеки — используемые зависимости и ссылки из других модулей
- другие общие свойства, такие как версия среды выполнения Java, которую мы собираемся скомпилировать
- Кодировка по умолчанию для исходных файлов или других ресурсов.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
|
<properties> <!-- encoding--> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <!--java version --> <java-version>1.7</java-version> <!-- plugin versions --> <ejb-plugin-version>2.3</ejb-plugin-version> <war-plugin-version>2.4</war-plugin-version> <ear-plugin-version>2.9</ear-plugin-version> <compiler-plugin-version>3.1</compiler-plugin-version> <!-- dependency versions --> <javaee-api-version>7.0</javaee-api-version> <!-- EJB spec version --> <ejb-spec-version>3.2</ejb-spec-version></properties> |
Давайте добавим после раздела свойств еще один важный элемент dependencyManagement. Здесь мы определим зависимости и их версии, которые могут потенциально использоваться в наших модулях приложения. В этом разделе мы на самом деле заботимся о версии, включении или исключении зависимостей от дочернего pom (то есть они не добавляются автоматически), а также об их сфере действия. Таким образом, раздел DependencyManagement предназначен для управления версиями в одном центральном месте.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
<dependencyManagement> <dependencies> <dependency> <groupId>javax</groupId> <artifactId>javaee-api</artifactId> <version>${javaee-api-version}</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${junit-version}</version> </dependency> </dependencies></dependencyManagement> |
Еще один последний, но важный раздел в нашем родительском pom, похожий на dependencyManagemt, называется pluginManagement и представляет собой раздел, в котором мы определим версии и общую конфигурацию всех подключаемых модулей maven, на которые будут ссылаться и которые будут использоваться во время конфигурации и упаковки нашего приложения. В приведенном ниже примере я определил один из самых основных, плагин компилятора, но, конечно, мне нужно больше!
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
|
<!-- Plugin management --><build> <pluginManagement> <plugins> <!-- compiler plugin --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>${compiler-plugin-version}</version> <configuration> <source>${java-version}</source> <target>${java-version}</target> <encoding>${project.build.sourceEncoding}</encoding> </configuration> </plugin> </plugins> </pluginManagement></build> |
Давайте добавим и настроим еще несколько плагинов, которые мы будем использовать позже. Добавьте их в раздел управления плагинов. Мы определяем плагин ejb, который собирается скомпилировать и упаковать наши ejb (s) и плагин war, который собирается упаковать нашу войну.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
<!-- ejb plugin --><plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ejb-plugin</artifactId> <version>${ejb-plugin-version}</version> <configuration> <ejbVersion>${ejb-spec-version}</ejbVersion> </configuration></plugin> <!-- war plugin -skinny wars mode! --><plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>${war-plugin-version}</version> <configuration> <failOnMissingWebXml>false</failOnMissingWebXml> <packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> </manifest> </archive> <webResources> <resource> <filtering>true</filtering> <directory>src/main/webapp</directory> <includes> <include>**/web.xml</include> </includes> </resource> </webResources> </configuration></plugin> |
Это сейчас
Вы можете скачать наш минимальный образец здесь (тег post1, bitbucket). В настоящее время кажется, что мы ничего не завершили, но в конечном итоге определение чистого и конкретного родительского помона станет основой для остальной части работы, которую мы будем выполнять на следующих постах.
Очки для изучения
- стандартная компоновка maven
- родительский пом
- важность зависимостиManagement & PluginManagement
Ресурсы
- Maven3
- Учебник по Java EE 7
- Структура проекта Maven
- Родительский пом
- Что такое управление зависимостями?
- Что такое управление плагинами?
- Вы можете скачать приведенный выше код здесь .
| Ссылка: | Проект Java EE7 и Maven для новичков — часть 1 — простая структура проекта maven — родительский партнер нашего партнера по JCG Пэрис Апостолопулос в блоге Papo . |