#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 ожидает строгую иерархию с одним корнем, которая подходит только для самых простых проектов.