Кто использует мой артефакт maven?

Question

У меня есть система, состоящая из нескольких веб-приложений (войны) и библиотек (jar). Все они используют maven и находятся под моим контролем (исходный код, встроенные артефакты в Nexus, ...). Скажем, что приложение A использует библиотеку L1 напрямую и L2 косвенно (используется из L1). Я могу легко проверить дерево зависимостей сверху вниз от приложения, используя maven's dependency: tree или graph: plugins проекта. Но как я могу проверить, кто использует мою библиотеку? В моем примере я хочу знать, является ли A единственным приложением (или библиотекой), использующим L1, и что L2 используется из L1 и из какого-либо другого приложения, скажем B. Существует ли какой-либо плагин для maven или nexus или я должен попробовать написать для этого сценарий? Каковы ваши предложения?

Answer 1

Если вы хотите, чтобы достичь этого на уровне хранилища, Apache Archiva имеет «используемый» функции, перечисленные в соответствии с проектной информацией

.

Это похоже на то, что перечисляет mvnrepository.com в разделе «Используется» в описании артефакта.

К сожалению, Nexus похоже не предоставляет эквивалентную функцию.

Теперь я полагаю, что для этого было бы непросто поддерживать еще один репозиторий, но тогда это, вероятно, было бы проще, чем некоторые другие предложения, например, написать плагин для Nexus. Я считаю, что Archiva может быть настроен на прокси-сервер других репозиториев.

Update

На самом деле, есть также plugin for Nexus для достижения «используется» особенность.

Answer 2

Я не думаю, что есть способ Maven сделать это. При этом есть способы сделать это или подобные вещи. Вот несколько примеров:

• Откройте свои проекты в своей любимой среде IDE. Например, Eclipse поможет вам провести анализ воздействия на уровне класса, который в большинстве случаев может быть достаточно хорошим.

• Используйте простой «grep» в исходном каталоге. Это звучит немного brusk (а также о том, очевидное), может быть, но мы использовали это много

• Использование зависимостей инструментов анализа, такие как Sonargraph или Lattix

Answer 3

Насколько я знаю ничто по этим строкам не существует как инструмент с открытым исходным кодом. Вы можете написать плагин Nexus, который пересекает репо и проверяет использование вашего компонента во всех других компонентах, итерируя все помпы и анализируя их. Это было бы довольно тяжелой задачей для запуска, поскольку, поскольку она должна была бы смотреть на все компоненты и анализировать все помпы.

Аналогичным образом вы можете сделать это в локальном репозитории с помощью другого инструмента. Однако, вероятно, имеет смысл анализировать содержимое менеджера репо, а не локального репозитория.

Answer 4

Возможно, более интересно: что бы вы сделали с этой информацией? Сообщите разработчикам A больше не использовать библиотеку L1 или L2, потому что у нее критическая ошибка? На мой взгляд, вы должны иметь возможность создавать черный список зависимостей/родителей/плагинов в вашем менеджере репозитория. Как только проект пытается развернуть/загрузить себя с черным списком артефакта, он должен потерпеть неудачу. Я говорю uploading, а не downloading, потому что это может сломать много проектов. Насколько мне известно, это еще не доступно для любого репозитория-менеджера.

Answer 5

Один из способов решения этой проблемы находится вне самой Java: напишите сценарий мониторинга уровня ОС, который отслеживает каждый случай fopen() в файле jar под вопросом! Предполагая, что это в корпоративной среде, вам, возможно, придется подождать несколько недель (!), Чтобы разрешить всем, использующим процессы, доступ к библиотеке хотя бы один раз!

В Windows, вы можете использовать Sysinternals Process Monitor, чтобы сделать это: http://technet.microsoft.com/en-us/sysinternals/bb896645

В Unix вариантов, вы должны использовать DTrace или Трассирование.

Answer 6

Мне не известны публичные библиотеки для этой работы, поэтому я написал настраиваемое приложение, которое делает это для меня. Я работаю с распределением, которое объединяет более 70 артефактов. Много раз после изменения артефакта я хочу, чтобы изменения были обратно совместимы (т. Е. В зависимых артефактах не возникают ошибки компиляции). Чтобы достичь этого, было важно знать всех зависимых от модифицированного артефакта.

Следовательно, я написал приложение, которое сканирует все артефакты под каталогом (/ подкаталоги), извлекает их pom.xml и ищет (в разделе зависимостей pom) за появление модифицированного артефакта. (Я сделал это в java, хотя скрипт shell/windows может сделать это еще более компактно.)

Я с удовольствием передам код в github, если это может быть любой помощью.

Answer 7

Один из способов, который может удовлетворить ваши потребности, - создать мастер-помпу со всеми вашими проектами maven. Затем вы выполните следующую команду на master-pom:

mvn dependency:tree -DoutputType=graphml -DoutputFile=dependency.graphml 

Открыть сгенерированный файл в yEd.

Пользовались инструкции, приведенные здесь: http://www.summa-tech.com/blog/2011/04/12/a-visual-maven-dependency-tree-view/

Answer 8

ИМХО, а также из моего опыта, ищет технического решения такой задачи часто является излишним. Если причина, по которой вы хотите узнать, кто использует ваш артефакт (библиотека), состоит в том, что вы хотите обеспечить обратную совместимость при изменении артефакта или чего-то подобного, я думаю, что это лучше всего сделать, передав ваши изменения с использованием традиционных каналов, а также поощряйте другие команды, которые могут использовать вашу библиотеку, чтобы говорить об этом (блоги проекта, вики, электронная почта, хорошо известное место, где размещаются документы, Jour fixe и т. д.).

Теоретически вы можете написать сценарий, который сканирует каждый проект в вашем репозитории, а затем анализирует maven build.xml (при условии, что все они используют maven) и посмотреть, определили ли они зависимость от вашего артефакта. Если все проекты в вашей организации соответствуют стандартной структуре maven, должно быть легко написать один такой скрипт (хотя, если какой-либо из этих проектов имеет зависимость от вашего артефакта через транзитивную зависимость, все может стать немного более сложным).