Проблема заключается в количестве и дублировании зависимостей во всех этих poms, даже если у вас есть версии под контролем, просто поддерживать их в большом проекте очень сложно.
несколько похожих вопросов, но ничего подобного. Как вы справляетесь с этой ситуацией (типичный сценарий):
Проект из 8-11 дочерних проектов, имеющий родительский артефакт / проект и один основной проект, который в основном использует / объявляет эти другие как модули.
Проблема в том, что все проекты «строго» разделяют только общие зависимости, такие какtestng, logging, apache commons and stuff, Но всегда нравится3 из них используют 50-60% тех же самых специфических групп (апач-химия, крольчиха, абдера и т. Д.), Еще 2-3 из них также используют 50-60% тех же, но разных зависимостей. И основной использует много тех же самых deps.
Я не могу поместить эти "не строго" общие депы в родительский проект, чтобы другие могли их наследовать. Таким образом, только общие deps наследуются. И есть тонны повторяющихся зависимостей. И я могу управлять только их версиями через<dependencyManagement>.
Другой вариант заключается в том, что родительский pom содержит большинство зависимостей, но дочерние проекты наследуют даже те, которые им не нужны.
У меня может быть более одного родительского проекта, но это не так. Также наследование от родительского проекта может быть кошмаром, потому что вы не знаете, какие зависимости нужны проекту, если вы не задокументируете / не прокомментируете определение родительского pom должным образом.
Другой способ - создать артефакты pom, которые служат только контейнерами зависимостей - они объявляют определенные группы зависимостей, поэтому модули просто объявляют их для получения транзитивных зависимостей. Но вы бы хотели развернуть и совершить какое-то
Объявление OneDepArtifactjackrabit, abdera, chemistry
Объявление другого элемента DepArtifacthtmlcleaner, google-api, tika
Объявление ThirdDepArtifactspring, httpclient, selenium
Это огромный беспорядок, я не уверен, что я использую<dependencyManagement> правильно, это кажется полезным только для управления версиями зависимостей.
Я думал об адаптации разработки моего приложения к «многоуровневому дизайну Maven». Но если вы хотите создать Spring Services / Bean, которые просто используют различные библиотеки в одном модуле, вы не реализуете их в другом модуле, просто потому, что они используют библиотеку, которую использует другой модуль :-)