Maven MultiModule Project состав проекта в отношении обмена зависимостями

Question

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

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

Проблема в том, что все проекты «строго» разделяют только общие зависимости, например testng, logging, apache commons and stuff. Анкет Но всегда нравится 3 из них используют 50-60% одинаковых специфических DEP (Apache-Chemistry, Jackrabbit, Abdera и т. Д.), Другие 2-3 из них также используют 50-60% тех же, но разных зависимостей. И в основном используется много того же DEPS.

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

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

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

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

OneDepartifact объявляет jackrabit, abdera, chemistry

Еще один, объявляющий htmlcleaner, google-api, tika

Третий департафакт объявляет spring, httpclient, selenium

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

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

Answer 1

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

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

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

Answer 2

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

Я описываю хорошую многомодульную структуру проекта в этот ответ. Анкет Он также описывает использование агрегатора и наследства.

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

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

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

Answer 3

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

Родительский

<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>

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