Подтвердить что ты не робот

Как номера версий сортировки maven?

Maven, похоже, имеет возможность указывать диапазон версий, таких как <version>[1.2.3,)</version>, как maven определяет, что представляет собой более новую или более старую версию, когда нет последовательной схемы управления версиями, которой следуют все пакеты с открытым исходным кодом. Например

  • junit 4.10
  • slf4j 1.7.2
  • Спящий режим 4.1.7.Final
  • Spring 3.1.2.RELEASE

Как maven показывает, что представляет собой более старую или более новую версию пакета в maven? Что делать, если пакет использует буквы, поскольку версии номера что-то соответствуют линиям A, B, C или A2, A2, A4... и т.д.

Должен ли быть стандартный официальный путь к пакетам версий в maven? Являются ли общие пакеты с открытым исходным кодом, такие как spring и hibernate, игнорируя это соглашение о версии?

4b9b3361

Ответ 1

Пожалуйста, прочитайте другие ответы, которые могут быть более актуальными, чем этот.


Согласно этой ссылке, Maven требует, чтобы версия имела вид:

<MajorVersion [>. <MinorVersion [>. <IncrementalVersion ] ] [> - <BuildNumber | Qualifier ]>

Где MajorVersion, MinorVersion, IncrementalVersion и BuildNumber - все числовые, а Qualifier - строка. Если номер вашей версии не соответствует этому формату, тогда весь номер версии считается классификатором.

Эта ссылка объясняет, что вы можете "столкнуться с проблемами" (особенно с диапазонами версий Maven), если вы работаете с артефактами, которые не следуют этой схеме управления версиями. Глядя на исходный код Maven, который связан со статьей, весьма полезно.

Из приведенных вами примеров артефакты Hibernate и Spring, похоже, расходятся при использовании " . " Вместо " - " для разделения классификатора.

Некоторые эксперименты с моей стороны показывают, что DefaultArtifactVersion будет анализировать номера версий в точности так, как описано выше. То есть приведенный пример Spring (3.1.2.RELEASE) будет интерпретирован как:

  • Major: 0
  • Незначительный: 0
  • Добавочный: 0
  • Квалификатор: 3.1.2.RELEASE

Что еще более важно, сравнение двух номеров версий (если используется Maven 3.0 или новее) гораздо более гибкое. Номера версий разбиты на списки элементов (где либо . Или - отмечает границу между элементами, обратите внимание, что . Имеет более высокий приоритет, чем -). Затем выполняется сравнение, беря каждый элемент в срок и выполняя сравнение естественного порядка. Следовательно, 3.1.2.RELEASE будет рассматриваться как меньше, чем 3.1.3.RELEASE. Строки также сравниваются, поэтому 3.1.2.RELEASD будет выглядеть меньше, чем 3.1.2.RELEASE. Есть несколько специальных строк, которые имеют специальные эквиваленты, например, 3.1.3.a.1 будет сортировать так же, как 3.1.3.alpha.1

Однако пока сравнение более гибкое в новых версиях Maven. Границы диапазона версий по-прежнему оцениваются с использованием схемы Major: Minor: Incremental: Qualifier, поэтому, если вы используете диапазоны версий, гибкость менее полезна.

Ответ 2

Начиная с версии 3.0, Maven использует согласованную систему для сравнения номеров версий для отдельных версий и диапазонов версий. Система теперь имеет большой смысл, как только вы поняли несколько ошибок.

Все сравнения теперь выполняются ComparableVersion, который говорит:

  • смешивание ' - ' (тире) и ' . '(точечные) разделители,
  • переход между символами и цифрами также составляет разделитель: 1.0alpha1 => [1, 0, alpha, 1]
  • неограниченное количество компонентов версии,
  • Компоненты версии в тексте могут быть цифрами или строками,
  • Строки проверяются на наличие известных классификаторов, а порядок классификаторов используется для упорядочения версий. Хорошо известными классификаторами (без учета регистра) являются:
    • alpha или a
    • beta или b
    • milestone или m
    • rc или cr
    • snapshot
    • (пустая строка) или ga или final
    • sp
  • Неизвестные классификаторы рассматриваются после известных классификаторов в лексическом порядке (всегда без учета регистра),
  • тире обычно предшествует определителю и всегда менее важна, чем то, что предшествует точке.

Это означает, что версии выходят в следующем порядке, который, я думаю, имеет смысл, кроме 1.0-SNAPSHOT прямо посередине:

  • 1.0-beta1-SNAPSHOT
  • 1.0-beta1
  • 1.0-beta2-SNAPSHOT
  • 1.0-rc1-SNAPSHOT
  • 1.0-rc1
  • 1.0-SNAPSHOT
  • 1.0
  • 1.0-sp
  • 1.0-whatever
  • 1.0.1

Основной недостаток, который я обнаружил во всем этом, заключается в том, что snapshot происходит после beta или rc, поэтому у вас не может быть разработанной версии 1.0-SNAPSHOT, затем выпустите 1.0-beta1 или 1.0-rc1 и Maven поймет, что это позже.

Также обратите внимание, что 1.0-beta-1 точно так же, как 1.0beta1, а 1.0 точно так же, как 1 или 1.0.0.

Диапазоны версий теперь работают (почти) так, как вы ожидаете. Например, [1.0-alpha-SNAPSHOT,1.0] найдет 1.0-beta1-SNAPSHOT, 1.0-beta1, 1.0-rc1-SNAPSHOT, 1.0-rc1, 1.0-SNAPSHOT или 1.0, предпочитая более поздние элементы, чем более ранние. Это полностью поддерживается mvn versions:resolve resol, M2Eclipse и так далее.

Ответ 3

Это тест, который был написан непосредственно против класса ComparableVersion из Maven.

package org.codehaus.mojo.buildhelper.versioning;

import org.apache.maven.artifact.versioning.ComparableVersion;
import org.junit.Assert;
import org.junit.Test;

public class TempTest {
    @Test
    public void testVersions() {
        Assert.assertTrue(new ComparableVersion("1.0-beta1-SNAPSHOT").compareTo(
                new ComparableVersion("1.0-beta1")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-beta1").compareTo(
                new ComparableVersion("1.0-beta2-SNAPSHOT")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-beta2-SNAPSHOT").compareTo(
                new ComparableVersion("1.0-rc1-SNAPSHOT")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-rc1-SNAPSHOT").compareTo(
                new ComparableVersion("1.0-rc1")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-rc1").compareTo(
                new ComparableVersion("1.0-SNAPSHOT")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-SNAPSHOT").compareTo(
                new ComparableVersion("1.0")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0").compareTo(
                new ComparableVersion("1")) == 0);
        Assert.assertTrue(new ComparableVersion("1.0").compareTo(
                new ComparableVersion("1.0-sp")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-sp").compareTo(
                new ComparableVersion("1.0-whatever")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-whatever").compareTo(
                new ComparableVersion("1.0.1")) < 0);
    }
}

В этом тесте утверждается, что следующие версии считаются от минимального до самого высокого с помощью Maven:

  • 1,0-бета1-СНАПШОТ
  • 1,0-бета1
  • 1,0-бета2-СНАПШОТ
  • 1.0-rc1-СНАПШОТ
  • 1.0-rc1
  • 1,0-СНАПШОТ
  • 1.0 и 1 (они равны)
  • 1,0-зр
  • 1,0-то,
  • 1.0.1

Ответ 4

Ваше предположение об использовании major/minor/incremtal/и т.д. просто неверно. Сравнение выполняется в ComparableVersion, который содержит реализацию. Ctor вызовет parseVersion(...), который использует ComparableVersion, который хранится как экземпляр в DefaultArtifactVersion и используется во время compareTo(..)

Есть такие элементы, как getMajor.. и т.д., но они работают неправильно. Вот почему будет отмечен устаревшим.

Информация от Stehpen Collony верна для Maven 2, но не для Maven 3.