Рекомендации по установке сторонних библиотек в хранилище Maven?

Question

Допустим, у вас есть проект, который использует стороннюю библиотеку, такую ​​как API данных Google Analytics (gdata) , которая в настоящее время не развернута ни в одном из известных или популярных Maven публичные репозитории / индексы. Это не большая проблема, поскольку я могу просто развернуть артефакт в своем локальном репозитории Nexus.

Но есть ли в сообществе Maven лучшие практики для того, как я должен назвать «координаты» этой библиотеки в моем POM, поскольку стандарт для нее еще не установлен в публичных репозиториях?

Например, я должен ссылаться на него в моем POM как

<dependency>
    <groupId>com.google</groupId>
    <artifactId>gdata-analytics</artifactId>
    <version>1.0</version>
</dependency>

или есть какой-то лучший / более стандартный способ для меня придумать artifactId?

(И почему, черт возьми, провайдер из нескольких десятков библиотек, таких как Google, не приложит усилий к тому, чтобы разместить их в общедоступных общедоступных репозиториях / индексах Maven? и тем самым подтолкнуть к усыновлению?)

Answer 1

То, что вы сделали, вполне разумно. Несколько дополнительных очков:

• Когда Maven получает артефакт от Nexus, артефакт именуется как artifactId-версия. GroupId досадно опущен. Поэтому, когда артефакт перемещается (скажем, копируется в WEB-INF / lib в веб-приложении), ваш файл jar будет иметь вид « gdata-analytics-1.0 ». Это обычно не проблема. Однако, если имя артефакта очень распространено, например «util», вы можете включить информацию о группе в artifactId, например, используя groupId из « com.google » и artifactId из «». com.google.gdata-аналитика ». Да, повторение раздражает, но обеспечивает максимальную ясность в файловой системе и при поиске. У меня на самом деле была проблема, когда два разных groupIds оба имели jar " core-1.0 ", и один перезаписывал другой при копировании в каталог lib во время сборки.

• Второе предложение MattK о выравнивании вашего Maven versionId с любой версией, которой обычно известен артефакт.

• Если вы последуете совету Доминика по добавлению префикса groupId к названию вашей собственной компании (например, acme), это может упростить использование функции маршрутизации Nexus. Это гарантирует, что запросы на внутренние артефакты не будут переданы в Maven Central и попадут в их журналы (что может быть важно, если ваш groupId равен « acme.secret.project »!

Answer 2

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

Answer 3

У меня есть тенденция ставить префикс groupId своим собственным обычным идентификатором groupId. Это делает абсолютно ясным, что это то, что я загрузил, на случай, если это просочится в мир в целом.

Answer 4

Возможно, вам повезет: у Google есть собственный репозиторий Maven для своих проектов. Смотрите эту страницу: Инструкции

У меня было несколько архивных файлов Jar, поэтому мне приходилось загружать их на каждую рабочую станцию ​​(у нас пока нет общего репо в компании). Я поместил их в дерево исходного кода в каталоге / lib (не всегда хорошая идея) и добавил небольшой файл .BAT (или сценарий .sh), который содержал команды mvn install-file, чтобы загрузить репо моей локальной машины первым раз я строю. Если мне когда-нибудь понадобится обновить эти jar-файлы, я также обновлю файл load.bat и просто перезапущу его. В моих обстоятельствах я не ожидаю, что это случится чаще, чем раз в год, а может, и реже.

Answer 5

Многие проекты sourceforge используют имя проекта в groupid, например:

GroupId net.sf.json-lib ArtifactId json-lib

Это может быть уместно в примере Google, так как есть много артефактов Google.

Помните, что вы можете использовать тег classifer для различения двух банок в той же версии, но построены для разных целей, например, для разных JVM.