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

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

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

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

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

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

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

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

OneDepArtifact, объявляющий jackrabit, abdera, chemistry

AnotherDepArtifact, объявляющий htmlcleaner, google-api, tika

ThirdDepArtifact, объявляющий spring , httpclient, selenium

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

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