Я работаю в довольно большом проекте. У нас много проектов, и у каждого проекта есть зависимости. Мы используем 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 есть множество проектов, которые зависят, скажем, от object-pooling, что также зависит от многих других дополнительных компонентов, таких как (utils и multithreading).
Жизнь хороша для object-pooling разработчиков. Это довольно стабильный модуль, и все идет хорошо. Как и любой другой модуль, он также имеет зависимости. object-pooling разработчики все джентльмены и честные дамы и всякий раз, когда они находят критическую ошибку, они обновляют все проекты, которые зависят от object-pooling.
Теперь версия 1.9.3.1 из object-pooling стабильна и не имеет известных критических ошибок. Разработчики очень усердно работают над добавлением тонны новых функций и через некоторое время выпускают версию 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 и т. Д.). Как я уже сказал, жизнь хороша для object-pooling разработчиков. Версия 2.0.0.0 имеет новые функции и множество исправлений.
Тем не менее, ад не за горами для tps-reports разработчиков. Они уже давно используют 1.9.3.1 и, поскольку в этой версии нет известных ошибок, им комфортно работать со старой версией. Теперь они хотят использовать обновленный object-pooling, поэтому они обновляют свои 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 из object-pooling. Они копаются в журнале своего репозитория кода и обнаруживают, что не только парни object-pooling сделали тысячи коммитов, но и используют новейшие версии multithreading и utils, которые также имеют много коммитов.
Очевидно, что существует множество мест, где может возникнуть проблема. Это может быть object-pooling, это может быть взаимодействие между object-pooling и tps-reports, это может быть multithreading или utils или любая странная комбинация.
Вопрос (ы): Как вы, ребята, решаете подобные проблемы? Как вы управляете зависимостями от больших проектов, которые, в свою очередь, зависят от других проектов? Существуют ли какие-либо инструменты для помощи в этой задаче?
Спасибо!