Как центральный репозиторий сортирует номера версий?

Question

Я поддерживаю проект с открытым исходным кодом и публикую его выпуски в Центральном репозитории. Я только что опубликовал oshi-core-2.6, Версия в моем pom.xml для этого выпуска говорится:

<groupId>com.github.dblock</groupId>
<artifactId>oshi-core</artifactId>
<version>2.6</version>

Мой код требует Java 8 из-за функций Date/Time. Чтобы поддержать запрос пользователя, непосредственно перед этим выпуском я выпустил совместимую с Java 7 версию с использованием бэкпорта threeten со следующим в pom.xml:

<groupId>com.github.dblock</groupId>
<artifactId>oshi-core</artifactId>
<version>2.6-m-java7</version>

Принцип работы номеров версий в Maven гласит: "Все версии с классификатором старше, чем одна и та же версия без квалификатора (версия выпуска)". Еще один вопрос Stackru: как maven сортирует номера версий?, имеет ответ, ссылающийся на класс ComparableVersion, в котором перечислены несколько известных квалификаторов (альфа, бета, milestone, rc и моментальный снимок), которые должны сортироваться "раньше", чем выпуск ga / final (пустая строка).

После того, как в предыдущей версии у меня был собственный классификатор, я попытался использовать классификатор milestone (-m-) в моей версии java7, чтобы указать Maven, что это должен быть "более ранний" выпуск, чем 2.6. Однако поиск в Центральном репозитории показывает, что -m- версия "Последняя версия".

У меня есть вопросы:

• Почему сортировка центрального репозитория не соответствует документированной сортировке, которую я связал выше?
  • Используется ли более ранняя версия (до 3.2) сортировки Maven? Если да, то какую последовательную сортировку "Последней версии" можно ожидать?
  • Влияет ли дефис в имени моего артефакта?
• Есть ли лучший способ выпустить один и тот же номер версии в двух форматах, чем тот, который я выбрал (очевидно, плохо)?

Answer 1

Это работа для классификатора, а не для такой странной версии.

• 2.6 с классификатором: "JDK8" для JDK 8
• 2.6 с классификатором: "jdk7" и т. Д.

Кроме того, указанный документ Oracle действителен для Maven 2, но не для Maven 3.

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

Кроме того, вы ссылаетесь на ComparableVersion с альфа-версией и т. Д., Как Maven внутренне обрабатывает версии. Это можно посмотреть на модульном тесте для этого класса.

Но вы можете проверить поведение Maven с помощью небольшого инструмента командной строки:

java -jar apache-maven-3.3.9\lib\maven-artifact-3.3.9.jar 1.0.0 2.0.0
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.0.0 == 1
   1.0.0 < 2.0.0
2. 2.0.0 == 2

Используя это, вы можете увидеть, что Maven 3+ обрабатывает 2.6-m-java7 больше чем 2.6,

java -jar apache-maven-3.3.9\lib\maven-artifact-3.3.9.jar 2.6-m-java7 2.6
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 2.6-m-java7 == 2.6-m-java-7
   2.6-m-java7 > 2.6
2. 2.6 == 2.6

Так что это причина, почему центральный также обрабатывает это как большее.

Так что если вы используете такие вещи, как rc или же alpha вы увидите результат:

java -jar apache-maven-3.3.9\lib\maven-artifact-3.3.9.jar 2.6-alpha 2.6
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 2.6-alpha == 2.6-alpha
   2.6-alpha < 2.6
2. 2.6 == 2.6

java -jar apache-maven-3.3.9\lib\maven-artifact-3.3.9.jar 2.6-rc1 2.6
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 2.6-rc1 == 2.6-rc-1
   2.6-rc1 < 2.6
2. 2.6 == 2.6

(Вышеупомянутый инструмент CLI доступен начиная с Maven 3.2.5).

Лучшее решение - иметь модуль, который производит ваш обычный артефакт. Создайте дополнительный модуль, который содержит конфигурацию для JDK 7 и там вы можете использовать "threeten backport" и создать другой артефакт. Эти артефакты должны иметь классификаторы для таких целей.