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

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

8 голосов
/ 26 мая 2011

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

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

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

<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, но тогда мне придется заново объявить каждую зависимость (без версии) в каждом дочернем проекте.

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

Ответы [ 3 ]

6 голосов
/ 26 мая 2011

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

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

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

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

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

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

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

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

3 голосов
/ 18 ноября 2011

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

0 голосов
/ 13 апреля 2013

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

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

...