Создание групп зависимостей в Maven для повторного использования — включая «предоставленные» зависимости

#java #maven-2 #dependencies

#java #maven-2 #зависимости

Вопрос:

Я новичок в Maven и настраиваю свой первый проект maven. Я также создаю некоторые ресурсы maven в виде некоторых pom, которые могут быть унаследованы или использованы в качестве зависимостей в любых будущих проектах. Я хочу сгруппировать зависимости вместе и иметь возможность выборочно добавлять их в проект по мере необходимости.

Я прочитал эту статью о лучших практиках pom. Мне нравится идея группировки связанных зависимостей вместе в pom, а затем добавления pom в качестве зависимости в проект по мере необходимости. Этот подход отлично работает для зависимостей с областью компиляции. Однако это не удается для предоставленных областей, поскольку в качестве переходных зависимостей они опускаются.

Вот пример того, что я имею в виду: допустим, я группирую веб-зависимости для своих проектов в web-deps pom.xml . К ним относятся зависимости spring Framework с compile ограниченной областью действия, а также зависимость javaee с provided ограниченной областью действия:

 <modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>mvn-web-deps</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
        <version>${org.springframework.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-webmvc</artifactId>
        <version>${org.springframework.version}</version>
    </dependency>
    <dependency>
        <groupId>javaee</groupId>
        <artifactId>javaee-api</artifactId>
        <version>${javaee.version}</version>
        <scope>provided</scope>
    </dependency>
</dependencies>
  

Затем я добавляю этот pom в качестве зависимости в другой проект:

 <modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>project-a</artifactId>
<version>0.0.1-SNAPSHOT</version>

<dependency>
    <groupId>com.xyz</groupId>
    <artifactId>mvn-web-deps</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <type>pom</type>
</dependency>
  

Зависимости в mvn-web-deps теперь становятся транзитивными. Поскольку приведенная выше ссылка на зависимость является compile ограниченной, provided переходная зависимость опускается.

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

Каков правильный / лучший способ группировки зависимостей, избегая при этом проблем, подобных описанным выше?

Комментарии:

1. это не работает даже для области компиляции

Ответ №1:

Краткий ответ на ваш вопрос заключается в том, что вы должны включать «предоставленные» зависимости только локально, где код требует их компиляции, но не в родительском pom.xml или другие структуры. Указывает, что у вас есть «предоставленная» зависимость в глобальном pom.xml не имеет смысла для maven, потому что ему не нужно, чтобы он компилировался в таком pom.xml .

Вот длинный ответ:

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

Я научился разделять свои большие проекты на отдельные модули, каждый в своем собственном репозитории subversion. Я включаю зависимости по мере необходимости для каждого локального модуля в их pom.xml . Я выпускаю версионные теги каждого модуля по мере написания кода и по мере необходимости (т. Е. при тестировании и стабильности).

Я создаю свои большие проекты, создавая отдельный проект maven со своим собственным pom.xml и импортируйте мои модули как зависимости. Время от времени я обновляю версию модуля в зависимости, когда я выпускаю релиз. Затем я позволяю maven выполнять работу по извлечению всего, что ему нужно, транзитивно или нет, при компиляции / выпуске большого проекта.

Maven допускает всевозможные сложные конструкции и иерархию между pom.xmlsно, ИМХО, эта функция создает ненужный беспорядок и сложности. Пока это не принесло мне реальной пользы. Вначале я надеялся, что компиляция одной pom.xml все остальное было бы правильно скомпилировано каскадным способом. Я получил некоторый результат, но какой беспорядок поддерживать во всех глобальных pom.xml .

Раздельное освобождение артефактов моего модуля и создание моего проекта на основе этих выпусков сэкономили мне столько времени, что я могу только рекомендовать это. В общей сложности у меня меньше pom.xml для поддержания, и они также менее сложны. Для получения того же конечного результата…

Итак, если ваша единственная причина для создания глобального / структурного pom.xml в надежде сэкономить время, я рекомендую отказаться от этой идеи… Отдельный код в отдельных проектах, выпуск, а ЗАТЕМ глобальная компиляция.

Комментарии:

1. Спасибо за ответ. Возможно, я не очень четко изложил свою мотивацию использовать такие сгруппированные зависимости. Я тоже разбиваю свои проекты на модули. Чего я хочу добиться, группируя связанные зависимости вместе, так это возможности управлять ими в одном месте и повторно использовать их в разных проектах с помощью простой ссылки. продолжение..

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

Ответ №2:

Я пришел к выводу, что Maven не был разработан для такого варианта использования. В итоге у меня появился родительский файл, pom.xml в который были добавлены все библиотеки, которые я использую, в его <dependencyManagement> разделе. Любые новые проекты / модули, которые я создаю, pom.xml наследуются от родительского pom.xml элемента и добавляют каждую зависимость, которая им нужна, в свой собственный <dependencies> раздел, за вычетом версии. Эта схема позволяет мне управлять версиями для библиотек, которые я использую, и необходимыми для них объявлениями об ответах в одном месте. Еще одно преимущество (по сравнению с попытками каким-либо образом создавать пакеты зависимостей) заключается в том, что это дает более детальный контроль над библиотеками, добавляемыми в дочерние poms — добавляются только те зависимости, которые действительно необходимы.

Ответ №3:

Зависимости в предоставленной области действительно наследуются от родительского POM, но НЕ от POM, определенного как зависимости, и я считаю это слабостью Maven.

Учитывая, что у Maven также возникают трудности с добавлением модулей в качестве зависимостей между иерархиями модулей, я не могу сказать, что Maven является сложным инструментом для управления многомодульными проектами. Maven ожидает строгую иерархию с одним корнем, которая подходит только для самых простых проектов.