Как найти ненужные зависимости в мультипроекте maven?

Question

Если вы разрабатываете крупный развивающийся многомодульный проект maven, кажется неизбежным, что в poms есть некоторые зависимости, которые не нужны, так как они транзитивно включены в другие зависимости. Например, это происходит, если у вас есть модуль A, который изначально включает в себя C. Позже вы выполняете рефакторинг, и у вас есть A, зависящий от модуля B, который, в свою очередь, зависит от C. Если вы не будете достаточно осторожны, вы получите B и C Список зависимостей. Но, конечно, вам не нужно помещать C в помпу A, так как он все равно включен транзитивно. Есть ли инструмент для поиска таких ненужных зависимостей?

(Эти зависимости на самом деле не вредят, но они могут затенить вашу фактическую структуру модуля, и обычно лучше иметь меньше вещей в pom.: -)

Answer 1

В некоторой степени вы можете использовать dependency:analyze, но это не слишком полезно. Также проверьте JBoss Tattletale .

Некоторое время назад я запустил maven-storyteller-plugin , чтобы иметь возможность глубже анализировать poms, но проект очень далек от производства / публичного использования. Вы можете использовать цель storyteller:recount для анализа неиспользуемых / избыточных зависимостей.

Проблема всей истории в том, как определить «неиспользованные» вещи. Что вполне возможно проанализировать, например, ссылки на классы. Но это не сработает, если вы используете отражение - напрямую или не напрямую.

Обновление за ноябрь 2014 года.

Я только что переместил свой старый код плагина Storyteller на GitHub . Я обновлю его и отправлю в центральный, чтобы его можно было использовать другим.

Answer 2

I

лично используйте pom-редактор M2Eclipse для визуального просмотра дерева зависимостей (2D-дерева). Затем я смотрю в моих поставляемых (war, ear) каталогах lib. Затем все еще в M2Eclipse pom зависимостях просмотра я иду к каждой третьей стороне, и щелкните правой кнопкой мыши на зависимости, которую я хочу исключить (исключение добавляется автоматически в правой зависимости).

Нет золотых правил, просто несколько основных советов:

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

вам нужно угадать по названию зависимостей то, что вы должны будете исключить, лучший пример - парсеры, преобразователь, построитель документов: xalan, xerces, xalan alfred и co. попробуйте удалить их и использовать внутренний анализатор jdk1.6, общие вещи Apache, log4j также стоит посмотреть.

также регулярно просматривайте доставку lib, если у вас нет дубликатов библиотек с другой версией (решатель зависимостей maven должен этого избегать)

поднимитесь снизу вверх, начните с общих модулей, затем поднимитесь до уровня обслуживания, обрезая зависимости в каждом модуле, не пытайтесь запускаться в модулях ear / war, это будет слишком сложно

часто проверяйте, работает ли ваш конечный результат, проверяя или сравнивая старый результат с новым (особенно в каталоге web-inf / lib, который исчез с winmerge / beyoncompare)

Answer 3

Когда у вас есть A -> B, B -> C , а затем рефакторинг так, чтобы A -> (B, C) . IF это тот случай, когда A все еще компилируется с B , вы очень не хотите просто получить зависимость, потому что вы получаете это транзитивно.

Вспомните случай, когда A -> (B-1.0, C-1.0), B-1.0 -> C-1.0 . Все синхронизировано, поэтому, чтобы избежать «дублирования», вы удаляете C из зависимости A . Затем вы модернизируете A для использования B-2.0 -> C-2.0 . Вы начинаете видеть ошибки, потому что A хочет C-1.0 классов, но обнаружил C-2.0 классов. Несмотря на то, что в этом сценарии можно быстро выполнить согласование, при наличии множества зависимостей это гораздо меньше.

Вы очень хотите получить информацию в помпе A , которая говорит, что она явно ожидает найти C-1.0 в пути к классам, чтобы вы могли понять, когда у вас есть транзитивная зависимость конфликты. Опять же, Maven позаботится о том, чтобы «ближайшая» версия какой-либо конкретной банки оказалась на вашем пути к классам. Но когда дела идут плохо - вам нужны все метаданные зависимости, которые вы можете получить.

На более практическом замечании зависимость не используется, когда вы можете удалить ее из pom, и все ваши юнит-тесты / интеграционные / приемочные тесты все еще проходят. ; -)