Лучшие практики для установки сторонних библиотек в размещенный репозиторий Maven?

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

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

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

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

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

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


java maven-2
person matt b    schedule 05.05.2009    source источник

Ответы (5)


arrow_upward
3
arrow_downward

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

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

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

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

person Brian Laframboise    schedule 05.05.2009
comment
Все хорошие предложения - поэтому я принял этот ответ. Кстати, JAR, распространяемый google, который я развертывал, уже был назван gdata-analytics-1.0.jar, откуда я взял свой артефакт и номер версии. Должен любить хорошее название JAR - person matt b; 05.05.2009

arrow_upward
3
arrow_downward

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

person MattK    schedule 05.05.2009

arrow_upward
2
arrow_downward

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

person Dominic Mitchell    schedule 05.05.2009

arrow_upward
0
arrow_downward

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

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

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

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

person TimP    schedule 05.05.2009

arrow_upward
0
arrow_downward

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

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

person Grimarr    schedule 09.07.2009
comment
Спасибо, но мне кажется, что это репо не очень актуально. Артефакта, о котором я упоминал в своем исходном посте, нет. - person matt b; 09.07.2009