Управление зависимостями для больших проектов

Я работаю над довольно большим проектом. У нас много проектов, и у каждого проекта есть зависимости. Мы используем maven, и обычно у нас нет проблем. Итак, не вдаваясь в подробности, представьте, что для данного проекта, скажем, tps-reports раздел зависимостей pom.xml выглядит так:

  <name>TPS-Reports</name>
  <description>
   TPS Reports frontend.
  </description>
  <dependencies>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>gui-components</artifactId>
    <version>2.5</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>multithreading</artifactId>
    <version>3.7</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>utils</artifactId>
    <version>2.3.0.0</version>
   </dependency>
   <dependency>
    <!-- TODO: update to new version -->
    <groupId>com.initech</groupId>
    <artifactId>object-pooling</artifactId>
    <version>1.9.3.1</version>
   </dependency>
  </dependencies>

Теперь у Initech есть тонны проектов, которые зависят, скажем, от пула объектов , который также зависит от многих других компонентов, таких как ( utils и многопоточность ).

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

Теперь версия 1.9.3.1 из пул объектов стабилен и не содержит известных критических ошибок. Разработчики очень много работают, чтобы добавить массу новых функций, и через некоторое время они выпускают версию 2.0.0.0 . Конечно, между 1.9.3.1 и 2.0.0.0 есть промежуточные версии (например, 1.9.3.1 , 1.9.3.2 , 1.9.4.0 , 1.9.5.3 и так далее). Как я уже сказал, жизнь разработчиков пула объектов хороша. Версия 2.0.0.0 содержит новые функции и множество исправлений.

Однако, ад не за горами для разработчиков tps-отчетов . Они уже довольно давно используют 1.9.3.1 , и, поскольку в этой версии нет известных ошибок, им удобна старая версия. Теперь они хотят использовать обновленный пул объектов , поэтому они обновляют свой pom.xml , чтобы использовать версию 2.0.0.0 , и теперь это выглядит так:

  <name>TPS-Reports</name>
  <description>
   TPS Reports frontend.
  </description>
  <dependencies>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>gui-components</artifactId>
    <version>2.5</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>multithreading</artifactId>
    <version>3.7</version>
   </dependency>
   <dependency>
    <groupId>com.initech</groupId>
    <artifactId>utils</artifactId>
    <version>2.3.0.0</version>
   </dependency>
   <dependency>
    <!-- use object poooling's new features -->
    <groupId>com.initech</groupId>
    <artifactId>object-pooling</artifactId>
    <version>2.0.0.0</version>
   </dependency>
  </dependencies>

Они обнаруживают, что у них есть новые ошибки. Излишне говорить, что этих ошибок не существовало, когда они зависели от версии 1.9.3.1 объединения объектов . Они копаются в журнале своего репозитория кода и обнаруживают, что не только ребята из объединения объектов сделали тысячи коммитов, но также они используют новейшие версии многопоточности и utils , которые также имеют много коммитов.

Очевидно, существует множество мест, где может возникнуть проблема . Это может быть объектный пул , он может быть во взаимодействии между объектным пулом и tps-reports , это может быть многопоточность или utils или любая странная комбинация.

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

Спасибо!