При использовании maven-release-plugin, почему бы просто не обнаружить информацию scm из локального репо?

Question

Насколько я знаю, чтобы использовать плагин maven-release-plugin, вы должны поместить раздел scm в свой файл POM. Например:

<scm>
    <connection>scm:hg:ssh://[e-mail]/my_account/my_project</connection>
    <developerConnection>scm:hg:ssh://[e-mail]/my_account/my_project</developerConnection>
    <url>ssh://[e-mail]/my_account/my_project</url>
    <tag>HEAD</tag>
</scm>

Я понимаю, что эти данные используются, чтобы определить, что помечать и куда вносить изменения. Но разве эта информация уже недоступна, если у вас есть клонированный / проверенный код? Я немного борюсь с понятием, которое мне нужно сказать maven, какой код нужно пометить, когда он мог бы, по крайней мере, теоретически, просто спросить Git/HG/SVN/CVS, с каким кодом он имеет дело. Я подозреваю, что упускаю что-то в деталях, но я не уверен, что. Можно ли изменить код maven-release-plugin, чтобы удалить его как требование, или, по крайней мере, сделать автоопределение по умолчанию? Если нет, то может ли кто-нибудь представить контекст, почему это не сработает?

Answer 1

С одной стороны, GIT и Subversion могут иметь разные URI SCM для чтения-записи и доступа только для чтения.

Это то, что разные <connection> а также <developerConnection> URI должны захватывать. Первый - это URI, которому гарантирован доступ на чтение. Вторым является URI, который гарантирует доступ для записи.

Очень часто из проверенного хранилища невозможно вывести канонические URI.

Например, я мог бы проверить собственный репозиторий Subversion через svn: протокол и IP-адрес сервера, но внешние участники должны будут использовать https:// с именем хоста.

Или даже с GIT-репозиториями, на Github у вас разные URI для разных механизмов доступа, например

• https://github.com/stephenc/eaio-uuid.git (чтение-запись с использованием имени пользователя / пароля или OAuth)
• [e-mail]:stephenc/eaio-uuid.git (чтение-запись с использованием идентификации частного ключа SSH)
• git://github.com/stephenc/eaio-uuid.git (только для анонимного чтения)

Не берите в голову, что Вы, возможно, проверили git://github.com/zznate/eaio-uuid.git или клонировали локальную проверку, другими словами, ваш локальный git-репозиторий может указывать, что "upstream" ../eaio-uuid-from-nate и не [e-mail]:stephenc/eaio-uuid.git

Я согласен, что для некоторых инструментов SCM вы можете автоматически определять... например, если вы знаете, что источник извлечен из, например, AccuRev, вы должны быть в порядке, предполагая его детали... пока вы не нажмете Subversion или GIT или CVS или т. д. модуль кода извлечен в рабочую область AccuRev (правдивая история), чтобы можно было обновлять извлекаемый тег.

Короче говоря, код обнаружения должен быть чертовски уверен, что вы не используете две системы SCM одновременно, чтобы быть уверенным, какой из них является основным SCM... а другой SCM может даже не оставлять файлы маркеров на диске для вынюхивать (AccuRev, например, не... поэтому я выбрал его)

Единственный безопасный способ - потребовать, чтобы pom определил, по крайней мере, систему SCM, а для тех систем SCM, где URI не может быть надежно выведен (например, CVS, Subversion, GIT, HG, фактически большинство из них), требуется URI для быть уточненным.