Как номера версий сортировки 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, игнорируя это соглашение о версии?
Ответы
Ответ 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.