Как найти unneccesary зависимости в знатоке многопроектными?

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

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

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

Обновление ноябрь 2014.

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

Когда у вас есть A -> B, B -> C, а затем рефактор такой, что A -> (B, C). ЕСЛИ это тот случай, когда 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. Хотя в этом сценарии можно быстро примириться, это гораздо менее вероятно, когда у вас много зависимостей.

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

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

Я

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

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

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

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

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

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

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