Композиция мультимодульного проекта Maven относительно разделения зависимостей

Question

Есть несколько похожих вопросов, но ничего подобного. Как вы справляетесь с этой ситуацией (типичный сценарий):

Проект из 8-11 дочерних проектов, имеющий родительский артефакт / проект и один главный проект, который в основном использует / объявляет эти другие как модули.

Проблема в том, что все проекты "строго" разделяют только общие зависимости, такие как testng, logging, apache commons and stuff. Но всегда, как 3 из них используют 50-60% тех же самых специфических депов (apache-chemistry, jackrabbit, abdera и т. Д.), Еще 2-3 из них также используют 50-60% тех же, но разных зависимостей , И основной использует много одинаковых deps.

Я не могу поместить эти "не строго" общие депы в родительский проект, чтобы другие могли их наследовать. Таким образом, только общие deps наследуются. И есть тонны повторяющихся зависимостей. И я могу управлять только их версиями через <dependencyManagement>.

Другой вариант - родительский pom содержит большинство зависимостей, но дочерние проекты наследуют даже те, которые им не нужны.

У меня может быть более одного родительского проекта, но это не так. Также наследование от родительского проекта может быть кошмаром, потому что вы не знаете, какие зависимости нужны проекту, если вы не задокументируете / не прокомментируете определение родительского pom должным образом.

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

Объявление OneDepArtifact jackrabit, abdera, chemistry

Объявление другогоDepArtifact htmlcleaner, google-api, tika

Объявление ThirdDepArtifact spring, httpclient, selenium

Это большой беспорядок, я не уверен, правильно ли я использую <dependencyManagement>, кажется, он полезен только для управления версиями зависимостей.

Я думал об адаптации разработки моего приложения к "многоуровневому дизайну Maven". Но если вы хотите создать Spring-сервисы / компоненты, которые просто используют различные библиотеки в одном модуле, вы не реализуете их в другом модуле только потому, что они используют библиотеку, которую использует другой модуль: -)

Answer 1

Maven 3.1 должен решить эту проблему, введя "mixins". Тем временем кажется, что я могу получить большинство необходимых функций при правильном использовании профилей, как я описал в этом сообщении в блоге:

http://weblogs.java.net/blog/fabriziogiudici/archive/2011/07/19/maven-pom-composition-means-profiles

Пожалуйста, дайте мне знать, считаете ли вы это полезным.

Answer 2

Я знаю, вы сказали, что это может быть кошмар, но я твердо чувствую, что наследство между вашими родителями - это путь.

Я описываю хорошую многомодульную структуру проекта в этом ответе . Также описывается использование агрегатора и наследования цепочек родителей.

Некоторые вещи, которые помогут вам поддерживать порядок и разум ...

• Используйте хорошие соглашения об именах; не просто называйте родительские проекты parent1 и parent2. Используйте имена, которые описывают, какие виды зависимостей и другие вещи они настраивают, чтобы люди могли интуитивно знать, когда их использовать.
• Используйте функцию выпуска / развертывания maven, чтобы они корректно версионировались в вашем репозитории и всегда ссылались на артефакты с фиксированной версией. Отказ от использования SNAPSHOT - это первый шаг к созданию детерминированных, воспроизводимых сборок. Отладка проблем, когда все меняется на лету, очень сложна.
• Не полагайтесь на файл pom.xml, чтобы узнать, какие зависимости нужны вашему проекту. Это позволит вам избежать наследования и других вещей, таких как пользовательские профили. Вы должны использовать maven-dependency-plugin для выполнения этих задач анализа. Есть такие команды, как mvn dependency:tree, который показывает все зависимости проекта, и mvn dependency:analyze, который показывает неиспользуемые зависимости.

Надеюсь, благодаря этому совету наследование родительского POM-файла не будет таким сложным и кошмарным. Удачи!

Answer 3

Если в основном это элемент управления версией (числом) - почему бы не указать только версию зависимости в качестве свойства в родительском проекте и использовать ее в дочерних проектах, например

Parent

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>foo.bar</groupId>
    <artifactId>maven-parent</artifactId>
    <version>0.0.1</version>
    <packaging>pom</packaging>

    <properties>
        <log4j.version>1.2.16</log4j.version>
    </properties>

</project>

Дочерний

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <artifactId>maven-parent</artifactId>
        <groupId>foo.bar</groupId>
        <version>0.0.1</version>
    </parent>

    <groupId>foo.bar</groupId>
    <artifactId>maven-child</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>${log4j.version}</version>
        </dependency>
    </dependencies>

</project>

Это простое решение, которое позволяет указывать конкретные зависимости проекта с согласованными номерами версий.