Это один из симптомов чрезмерной модуляции.
Однажды я работал в компании с примерно двадцатью разработчиками и более шестидесяти различными активными проектами в репозитории SVN. Каждый проект имел свой собственный скрипт сборки и создавал файл JAR, который зависел как минимум от полдюжины или около того других проектов. Управление всеми этими зависимостями было настолько сложным, что мы потратили кучу времени, пытаясь (безуспешно, я мог бы добавить) настроить проекты maven на автоматическую загрузку всех правильных библиотек (и правильных версий) для всех этих маленьких микропроектов.
Самое смешное (для меня) в том, что это был всего лишь один проект, и мы даже не распространяли его во внешнем мире. Это было размещенное приложение с веб-интерфейсом, работающее на одном кластере серверов.
Sheesh.
Другим побочным эффектом архитектуры было то, что одни и те же функциональные возможности дублировались снова и снова (не всегда с одинаковыми алгоритмами или, если на то пошло, результатами) в нескольких разных проектах. Я думаю, что одна из причин была в том, что люди не хотели вводить новую зависимость от всего подпроекта только для того, чтобы получить доступ к нескольким его классам. Но я думаю, что другой причиной было то, что люди просто не знали, где и где существовал код, и вместо того, чтобы искать код, который они хотели бы использовать повторно, они просто переписали бы его в своем собственном проекте.
Конечно, модульность, как правило, хорошая вещь.
Но, как и все хорошее, его можно довести до смешных крайностей.
Мой совет - найти эти циклические зависимости и объединить проекты в более крупные куски, поскольку разбивка текущего проекта, вероятно, представляет собой ложную модульность. Лучше разделить ваш большой проект на несколько хорошо разделенных модулей, чем иметь миллионы псевдомодулей, создающих искусственные границы между логически связанными классами.