Relativepath maven что это

Сборка Java-проекта с использованием Maven

Этот урок освещает создание вами простого Java-приложения с использованием Maven.

Что вы создадите

Вы создадите простое приложение и соберете его с помощью Maven.

Что вам потребуется

• Примерно 15 минут свободного времени
• Любимый текстовый редактор или IDE
• JDK 6 и выше

Как проходить этот урок

Как и большинство уроков по Spring, вы можете начать с нуля и выполнять каждый шаг, либо пропустить базовые шаги, которые вам уже знакомы. В любом случае, вы в конечном итоге получите рабочий код.

Чтобы начать с нуля, перейдите в Настройка проекта.

• Загрузите и распакуйте архив с кодом этого урока, либо кнонируйте из репозитория с помощью Git: git clone https://github.com/spring-guides/gs-maven.git
• Перейдите в каталог gs-maven/initial
• Забегая вперед, установите Maven

Когда вы закончите, можете сравнить получившийся результат с образцом в gs-maven/complete .

Настройка проекта

Для начала вам необходимо настроить Java-проект перед тем, как собрать его Maven’ом. Т.к. урок посвящен Maven, сделаем проект максимально простым, насколько это возможно.

Создание структуры каталогов

В выбранном вами каталоге проекта создайте следующую структуру каталогов; к примеру, командой mkdir -p src/main/java/hello для *nix систем:

+-- src +-- main +-- java +-- hello

Внутри src/main/java/hello директории вы можете создать любые Java-классы, какие вы хотите. Для простоты и согласованности с остальной частью урока, Spring рекомендует вам создать два класса: HelloWorld.java и Greeter.java .

package hello; public class HelloWorld < public static void main(String[] args) < Greeter greeter = new Greeter(); System.out.println(greeter.sayHello()); >>

package hello; public class Greeter < public String sayHello() < return "Hello world!"; >>

Теперь, когда у вас есть проект, который вы можете собрать с Maven, вам нужно установит сам Maven.

Maven можно получить, скачав zip-файл с maven.apache.org/download.cgi. Необходимы только бинарные файлы, так что ищите ссылку на архив с именем apache-maven-version-bin.zip или apache-maven-version-bin.tar.gz.

Распакуйте архив и добавьте путь к каталогу bin в переменную окружения path.

Чтобы протестировать правильность установки Maven, запустите в командной строке:

mvn -v

Если всё было сделано правильно, то вы увидите сообщение примерно такого содержания:

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 07:51:28-0600) Maven home: /usr/share/maven Java version: 1.7.0_09, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.8.3", arch: "x86_64", family: "mac"

Теперь у вас есть установленный Maven.

Создание простой сборки Maven

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

Создайте файл с названием pom.xml в корневом каталоге проекта и наполните его следующим содержанием:

 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 
4.0.0 
org.springframework 
gs-maven 
jar 
0.1.0
 
 
 
 
org.apache.maven.plugins 
maven-shade-plugin 
2.1 
 
 
package 
 
shade 
 
 
 
 implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> 
hello.HelloWorld 
 
 
 
 
 
 
 

За исключением дополнительного элемента , это простейший из pom.xml файлов, необходимый для сборки Java проекта. Он включает следующие детали конфигурации проекта:

• — версия POM-модели (всегда 4.0.0)
• — группа или организация, к которой принадлежит проект. Чаще всего выражается в виде перевернутого наоборот доменного имени
• — имя, которое будет передано библиотеке экземпляра(artifact) проекта (к примеру, имя его JAR или WAR файла)
• — версия, с которой будет собран проект
• — как проект должен быть упакован. По умолчанию, с «jar» упаковывается в JAR-файл, «war» — WAR-файл

Когда речь заходит о выборе схемы управления версиями, Spring рекомендует [семантическое управление версиями] semver.org подход.

На данном этапе мы имеем минимальное, но уже рабочее определение Maven-проекта.

Сборка Java кода

Теперь все готово для сборки проекта Maven’ом. Вы можете выполнить несколько этапов жизненного цикла сборки, включая компиляцию кода, создание библиотеки пакета(такого, как JAR-файл) и установку библиотеки в локальный репозиторий Maven зависимостей.

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

mvn compile

Этим вы запустите Maven, передав ему указание на выполнение задачи compile. Когда он закончит, вы должны найни скомпилированные .class файлы в target/classes директории.

Вряд ли вы захотите распостранять или работать напрямую с .class файлами, поэтому вам полее подойдет выполнение задачи package:

mvn package

Задача package включает компиляцию вашего Java кода, запуск тестов, а в конце упаковывает в JAR-файл в target директории. Название JAR-файла будет основано на и . К примеру, с минимальным pom.xml(см. выше), JAR-файл будет иметь название gs-maven-initial-0.1.0.jar.

Если вы изменили значение с «jar» на «war», то результатом будет WAR-файл в target директории вместо JAR-файла.

Maven также хранит репозиторий зависимостей на вашей локальной машине(обычно в .m2/repository директории в вашей домашней папке) для быстрого доступа к зависимостям проекта. Если вы хотите добавить JAR-файл вашего проекта в локальный репозиторий, тогда вам необходимо выполнить задачу install :

mvn install

Задача install включает компиляцию, тестирование, упаковку кода проекта, а затем копирование в локальный репозиторий, тем самым другие проекты смогут ссылаться на него как на зависимость.

Говоря о зависимостях, пришло время объявлять зависимости в Maven сборке.

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

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

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

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

package hello; import org.joda.time.LocalTime; public class HelloWorld < public static void main(String[] args) < LocalTime currentTime = new LocalTime(); System.out.println("The current local time is: " + currentTime); Greeter greeter = new Greeter(); System.out.println(greeter.sayHello()); >>

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

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

 
 
joda-time 
joda-time 
2.2 

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

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

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

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

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

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

 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 
4.0.0 
org.springframework 
gs-maven 
jar 
0.1.0
 
 
 
 
joda-time 
joda-time 
2.2 
 
 

 
 
 
 
org.apache.maven.plugins 
maven-shade-plugin 
2.1 
 
 
package 
 
shade 
 
 
 
 implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> 
hello.HelloWorld 
 
 
 
 
 
 
 

Полная версия pom.xml использует Maven Shade Plugin как удобный инструмент для создание выполняемого JAR-файла. Целью данного урока является показать, как начать работать с Maven, не используя, в частности, этот плагин.

Итог

Поздравляем! Вы создали простой, но эффективный файл сборки Maven для сборки Java проектов.

С оригинальным текстом урока вы можете ознакомиться на spring.io.

Introduction to the POM

A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this is the build directory, which is target ; the source directory, which is src/main/java ; the test source directory, which is src/test/java ; and so on. When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.

Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.

Super POM

The Super POM is Maven’s default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects.

You can see the Super POM for Maven 3.6.3 in Maven Core reference documentation.

Minimal POM

The minimum requirement for a POM are the following:

• project root
• modelVersion — should be set to 4.0.0
• groupId — the id of the project’s group.
• artifactId — the id of the artifact (project)
• version — the version of the artifact under the specified group

Here’s an example:

 4.0.0 com.mycompany.app my-app 1 

A POM requires that its groupId, artifactId, and version be configured. These three values form the project’s fully qualified artifact name. This is in the form of ::. As for the example above, its fully qualified artifact name is «com.mycompany.app:my-app:1».

Also, as mentioned in the first section, if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value «jar» would be used.

Furthermore, you can see that in the minimal POM the repositories were not specified. If you build your project using the minimal POM, it would inherit the repositories configuration in the Super POM. Therefore when Maven sees the dependencies in the minimal POM, it would know that these dependencies will be downloaded from https://repo.maven.apache.org/maven2 which was specified in the Super POM.

Project Inheritance

Elements in the POM that are merged are the following:

• dependencies
• developers and contributors
• plugin lists (including reports)
• plugin executions with matching ids
• plugin configuration
• resources

The Super POM is one example of project inheritance, however you can also introduce your own parent POMs by specifying the parent element in the POM, as demonstrated in the following examples.

Example 1

The Scenario

As an example, let us reuse our previous artifact, com.mycompany.app:my-app:1. And let us introduce another artifact, com.mycompany.app:my-module:1.

 4.0.0 com.mycompany.app my-module 1 

And let us specify their directory structure as the following:

. |-- my-module | `-- pom.xml `-- pom.xml

Note: my-module/pom.xml is the POM of com.mycompany.app:my-module:1 while pom.xml is the POM of com.mycompany.app:my-app:1

The Solution

Now, if we were to turn com.mycompany.app:my-app:1 into a parent artifact of com.mycompany.app:my-module:1,we will have to modify com.mycompany.app:my-module:1’s POM to the following configuration:

com.mycompany.app:my-module:1’s POM

 4.0.0 com.mycompany.app my-app 1  com.mycompany.app my-module 1 

Notice that we now have an added section, the parent section. This section allows us to specify which artifact is the parent of our POM. And we do so by specifying the fully qualified artifact name of the parent POM. With this setup, our module can now inherit some of the properties of our parent POM.

Alternatively, if you want the groupId or the version of your modules to be the same as their parents, you can remove the groupId or the version identity of your module in its POM.

 4.0.0 com.mycompany.app my-app 1  my-module 

This allows the module to inherit the groupId or the version of its parent POM.

Example 2

The Scenario

However, that would work if the parent project was already installed in our local repository or was in that specific directory structure (parent pom.xml is one directory higher than that of the module’s pom.xml ).

But what if the parent is not yet installed and if the directory structure is as in the following example?

. |-- my-module | `-- pom.xml `-- parent `-- pom.xml

The Solution

To address this directory structure (or any other directory structure), we would have to add the element to our parent section.

 4.0.0 com.mycompany.app my-app 1 ../parent/pom.xml  my-module 

As the name suggests, it’s the relative path from the module’s pom.xml to the parent’s pom.xml .

Project Aggregation

Project Aggregation is similar to Project Inheritance. But instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the parent project now knows its modules, and if a Maven command is invoked against the parent project, that Maven command will then be executed to the parent’s modules as well. To do Project Aggregation, you must do the following:

• Change the parent POMs packaging to the value «pom».
• Specify in the parent POM the directories of its modules (children POMs).

Example 3

The Scenario

Given the previous original artifact POMs and directory structure:

com.mycompany.app:my-app:1’s POM

 4.0.0 com.mycompany.app my-app 1 

com.mycompany.app:my-module:1’s POM

 4.0.0 com.mycompany.app my-module 1 

directory structure

. |-- my-module | `-- pom.xml `-- pom.xml

The Solution

If we are to aggregate my-module into my-app, we would only have to modify my-app.

 4.0.0 com.mycompany.app my-app 1 pom my-module  

In the revised com.mycompany.app:my-app:1, the packaging section and the modules sections were added. For the packaging, its value was set to «pom», and for the modules section, we have the element my-module . The value of is the relative path from the com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1’s POM (by practice, we use the module’s artifactId as the module directory’s name).

Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same Maven command would be ran against com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handle project aggregation differently.

Example 4

The Scenario

But what if we change the directory structure to the following:

. |-- my-module | `-- pom.xml `-- parent `-- pom.xml

How would the parent POM specify its modules?

The Solution

The answer? — the same way as Example 3, by specifying the path to the module.

 4.0.0 com.mycompany.app my-app 1 pom ../my-module  

Project Inheritance vs Project Aggregation

If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.

And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you’d only have to build the parent and the rest will follow.

But of course, you can have both Project Inheritance and Project Aggregation. Meaning, you can have your modules specify a parent project, and at the same time, have that parent project specify those Maven projects as its modules. You’d just have to apply all three rules:

• Specify in every child POM who their parent POM is.
• Change the parent POMs packaging to the value «pom» .
• Specify in the parent POM the directories of its modules (children POMs)

Example 5

The Scenario

Given the previous original artifact POMs again,

com.mycompany.app:my-app:1’s POM

 4.0.0 com.mycompany.app my-app 1 

com.mycompany.app:my-module:1’s POM

 4.0.0 com.mycompany.app my-module 1 

and this directory structure

. |-- my-module | `-- pom.xml `-- parent `-- pom.xml

The Solution

To do both project inheritance and aggregation, you only have to apply all three rules.

com.mycompany.app:my-app:1’s POM

 4.0.0 com.mycompany.app my-app 1 pom ../my-module  

com.mycompany.app:my-module:1’s POM

 4.0.0 com.mycompany.app my-app 1 ../parent/pom.xml  my-module 

NOTE: Profile inheritance the same inheritance strategy as used for the POM itself.

Project Interpolation and Variables

One of the practices that Maven encourages is don’t repeat yourself. However, there are circumstances where you will need to use the same value in several different locations. To assist in ensuring the value is only specified once, Maven allows you to use both your own and pre-defined variables in the POM.

For example, to access the project.version variable, you would reference it like so:

One factor to note is that these variables are processed after inheritance as outlined above. This means that if a parent project uses a variable, then its definition in the child, not the parent, will be the one eventually used.

Available Variables

Project Model Variables

Any field of the model that is a single value element can be referenced as a variable. For example, $ , $ , $ and so on. Refer to the POM reference to see a full list of properties.

These variables are all referenced by the prefix » project. «. You may also see references with pom. as the prefix, or the prefix omitted entirely — these forms are now deprecated and should not be used.

Special Variables

project.basedir	The directory that the current project resides in.
project.baseUri	The directory that the current project resides in, represented as an URI. Since Maven 2.1.0
maven.build.timestamp	The timestamp that denotes the start of the build (UTC). Since Maven 2.1.0-M1

The format of the build timestamp can be customized by declaring the property maven.build.timestamp.format as shown in the example below:

 . yyyy-MM-dd'T'HH:mm:ss'Z'  . 

The format pattern has to comply with the rules given in the API documentation for SimpleDateFormat. If the property is not present, the format defaults to the value already given in the example.

Properties

You are also able to reference any properties defined in the project as a variable. Consider the following example:

 . 3.0   org.apache.maven maven-artifact $ org.apache.maven maven-core $  . 

Идеальный мавен. Часть 2: структура проекта

Это вторая статья, посвященная мавену и его использованию для организации моих проектов. Целью этой статьи будет структура проекта под управлением мавен. Особых откровений вы не найдёте, скорее набор общих правил для моих проектов. Первую статью можно прочитать здесь.

Структура проекта

Как я уже сказал, я не буду описывать здесь типовую структуру проекта на мавен – вы её знаете или легко можете найти по ссылке: Standard Directory Layout. В этой части я остановлюсь на особенностях, которые я применяю в своих проектах, итак:

Модули

Практически любой мой проект имеет несколько модулей. Практика показывает, что, когда необходимо добавить еще один модуль в проект это гораздо проще сделать в случае изначально модульного проекта. В моих проектах существует 3 типа «модулей» – POM (всегда один), несколько девелоперских модулей с кодом и BOM – если дев. модулей больше одного. В принципе POM это не модуль в понимании мавен, но я всегда оформляю его почти как «модуль» (покажу ниже). В итоге получается, что-то вроде такого:

Общие принципы для всех POM‘ов – в них содержится минимум информации необходимый для построения проекта, все версии, все настройки плагинов, не специфичные для данного проекта, находятся в супер («корпоративном») POM’е. Все «модули», кроме проектного POM‘а, содержат ссылку на локальную версию родителя relativePath .

Проектный POM

Начнём с проектного POM‘а. Я практически всегда убираю его в отдельный каталог с именем pom. Делаю я так по нескольким причинам:

• Импорт проектов в Eclipse. Это самый постой способ избежать импорта модулей вместе с проектнымPOM‘ем.
• Разделяются файлы относящиеся к целому проекту (например .htignore , на картинке выше) и «проекту» импортированному в IDE (например .settings , который генерирует Eclipse для каждого «модуля» при импорте).
• Мне так визуально проще это воспринимать как «модуль» проекта.

Проектный POM содержит ссылку на супер POM, список модулей, версии проектов от которых он зависит (не библиотек третьих стран, а именно проектов, которые находятся параллельно в разработке в этой компании) и определение версии для модулей и проектов (dependencyManagement). Вот типичный POM для маленького проекта:

  4.0.0 org.jresearch.pom org.jresearch 29-SNAPSHOT  org.jresearch.commons.base.resources org.jresearch.commons.base.resources.pom 1.0.43-SNAPSHOT pom ../api ../impl ../test ../bom  1.0.34-SNAPSHOT    org.jresearch.commons.base org.jresearch.commons.base.domain $ org.jresearch.commons.base.resources org.jresearch.commons.base.resources.api $ org.jresearch.commons.base.resources org.jresearch.commons.base.resources.test $   

В этом примере:
версия проекта, от которого он зависит

  1.0.34-SNAPSHOT 

и определение версии для модулей и проектов

   org.jresearch.commons.base org.jresearch.commons.base.domain $ org.jresearch.commons.base.resources org.jresearch.commons.base.resources.api $  

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

BOM POM

Это «bill of materials» — список артефактов, которые экспортирует проект. В моих проектах он появляется если количество девелоперских модулей больше одного. Это позволяет управлять версиями зависимостей между внутренними проектами с помощью только одной записи в секции dependencyManagement .
Пример BOM:

  4.0.0 org.jresearch.commons.base.resources.pom org.jresearch.commons.base.resources 1.0.43-SNAPSHOT ../pom/pom.xml  pom org.jresearch.commons.base.resources.bom JRS-COMMONS: Base resource (DAO) BOM   org.jresearch.commons.base.resources org.jresearch.commons.base.resources.api $ org.jresearch.commons.base.resources org.jresearch.commons.base.resources.impl $ org.jresearch.commons.base.resources org.jresearch.commons.base.resources.test $     

Модуль с кодом

Самый примитивный POM. Включает в себя ссылку на проектный POM, artefactId, список зависимостей без версий. При необходимости секцию build c ссылками на плагины. Версия и groupId наследуются из родительского POM’а.
Пример:

  4.0.0 org.jresearch.commons.base.resources.pom org.jresearch.commons.base.resources 1.0.43-SNAPSHOT ../pom/pom.xml  org.jresearch.commons.base.resources.api  org.jresearch.commons.base org.jresearch.commons.base.domain  com.google.code.findbugs jsr305  joda-time joda-time   

Имя артефакта

groupId это имя пакета в Java для этого проекта – в последнее время это стало практически стандартом. С artifactId – немного чудесатей, для своих проектов я всегда беру имя группы плюс имя модуля, что-то вроде этого:

org.jresearch.orika.spring

Почему? Имя у итогового артефакта должно быть уникальным (слишком часто все сваливают в один каталог), саму идею я вынес и мира eclipse — так там именуются плагины. Поначалу непривычно, но оно достаточно уникально, придумать его очень просто, увидев в каталоге по имени очень быстро можно найти артефакт в репозитории и source control‘е.

Почему не использовать finalName в супер POM‘е (e.g. $< groupId>.$-$ )? Так сложилось исторически, на заре мавенизации очень много плагинов игнорировало правила, и проще было написать это руками. Сейчас, наверное, это не так.

Следовать этой конвенции с именами не обязательно. Главное, это уникальность имени итогового артефакта.

Общие принципы по структуре для моих проектов.

1. Версии зависимостей и плагинов только в супер или проектных POM‘ах
2. Все модули наследуют версию и группу, которые определены в проектном POM‘е.
3. Если я твёрдо (на 146%) уверен, что проект будет содержать только один модуль с кодом делаю классический мавен проект (e.g. https://bitbucket.org/JRS/open-base-util/src)
4. Если знаю, что модулей будет несколько добавляю сразу bom модуль (e.g. https://bitbucket.org/JRS/open-base-resources/src)
5. Если не уверен, то проект из одного модуля без BOM (e.g. https://bitbucket.org/JRS/open-base/src)
6. artifactId это всегда groupId + имя модуля
7. структура каталогов для проекта: корневой каталог – имя проекта (короткое), pom каталог для проектного POM’a, bom – для BOM POM‘а, остальные каталоги по имени модулей.
8. relativePath — во всех «модулях», кроме проектного POM‘а, один мавен проект – это один проект в source control. Все связи между проектами только через мавен.

По структуре проектов это, наверное, все.

Понимание тега Maven «relativePath» для родительского POM

В этом руководстве мы узнаем о разрешении Parent POM Maven . Во-первых, мы обнаружим поведение по умолчанию. Затем мы обсудим возможности его настройки.

2. Разрешение родительского POM по умолчанию​

Если мы хотим указать родительский POM, мы можем сделать это, назвав groupId , ArtiftId и version , так называемую координату GAV . Maven не разрешает родительский POM, сначала выполняя поиск в репозиториях . Мы можем найти подробности в документации по модели Maven и резюмировать поведение:

1. Если в родительской папке есть файл pom.xml , и если этот файл имеет совпадающую координату GAV, он классифицируется как родительский POM проекта.
2. Если нет, Maven возвращается к репозиториям.

Размещение проекта Maven в другом является лучшей практикой при управлении многомодульными проектами . Например, у нас есть проект агрегатора со следующей координатой GAV:

 groupId>com.foreach.maven-parent-pom-resolutiongroupId>   artifactId>aggregatorartifactId>   version>1.0.0-SNAPSHOTversion> 

Затем мы могли бы поместить модуль в подпапку и обратиться к агрегатору как к родителю:

Таким образом, POM module1 может включать в себя этот раздел:

 artifactId>module1artifactId>   parent>   groupId>com.foreach.maven-parent-pom-resolutiongroupId>   artifactId>aggregatorartifactId>   version>1.0.0-SNAPSHOTversion>   parent> 

Нет необходимости устанавливать агрегатор POM в репозиторий. И даже не нужно объявлять module1 в POM агрегатора. Но мы должны знать, что это применимо только для локальных проверок проекта (например, при сборке проекта). Если проект разрешается как зависимость от репозитория Maven, родительский POM также должен быть доступен в репозитории.

И мы должны убедиться, что агрегатор POM имеет соответствующую координату GAV. В противном случае мы получим ошибку сборки:

 [ERROR] Non-resolvable parent POM for com.foreach.maven-parent-pom-resolution:module1:1.0.0-SNAPSHOT:  Could not find artifact com.foreach.maven-parent-pom-resolution:aggregator:pom:1.0-SNAPSHOT  and 'parent.relativePath' points at wrong local POM @ line 7, column 13 

3. Настройка расположения родительского POM​

Если родительский POM не находится в родительской папке, нам нужно использовать тег relativePath для ссылки на местоположение. Например, если у нас есть второй модуль, который должен наследовать настройки от модуля1 , а не от агрегатора, мы должны назвать родственную папку:

 artifactId>module2artifactId>   parent>   groupId>com.foreach.maven-parent-pom-resolutiongroupId>   artifactId>module1artifactId>   version>1.0.0-SNAPSHOTversion>   relativePath>../module1/pom.xmlrelativePath>   parent> 

Конечно, мы должны использовать только те относительные пути, которые доступны в каждой среде (в основном пути в пределах одного и того же репозитория Git), чтобы обеспечить переносимость нашей сборки.

4. Отключить разрешение локального файла​

Чтобы пропустить локальный поиск файлов и напрямую искать родительский POM в репозиториях Maven, нам нужно явно установить относительный путь в пустое значение:

 parent>   groupId>com.foreachgroupId>   artifactId>external-projectartifactId>   version>1.0.0-SNAPSHOTversion>   relativePath/>   parent> 

Это должно быть лучшей практикой, когда мы наследуем от внешних проектов, таких как Spring Boot .

5. IDE​

Интересно, что IntelliJ IDEA (текущая версия: 2021.1.3) поставляется с подключаемым модулем Maven, который отличается от внешних сред выполнения Maven разрешением Parent POM. Отклоняясь от схемы Maven POM , он объясняет тег relativePath следующим образом:

[…] Maven сначала ищет родительский pom в реакторе текущих строительных проектов […]

Это означает, что для внутреннего разрешения IDE положение родительского POM не имеет значения, если родительский проект зарегистрирован как проект IntelliJ Maven. Это может быть полезно для простой разработки проектов без их явного создания (если они не входят в область действия одного и того же репозитория Git). Но если мы попытаемся собрать проект с внешней средой выполнения Maven, это не удастся.

6. Заключение​

В этой статье мы узнали, что Maven не разрешает родительские POM, сначала выполняя поиск в репозиториях Maven. Он скорее ищет его локально, и мы явно должны деактивировать это поведение при наследовании от внешних проектов. Кроме того, IDE могут дополнительно разрешать проекты в рабочей области, что может привести к ошибкам при использовании внешних сред выполнения Maven.

Как всегда, код примера доступен на GitHub .

• 1. Обзор
• 2. Разрешение родительского POM по умолчанию
• 3. Настройка расположения родительского POM
• 4. Отключить разрешение локального файла
• 5. IDE
• 6. Заключение