tutorial releases mvn instalar maven maven-3

releases - ¿Cómo ordena Maven los números de versión?



maven tutorial (4)

Desde la versión 3.0, Maven usa un sistema consistente para comparar números de versión tanto para versiones individuales como para rangos de versiones. El sistema ahora tiene mucho sentido, una vez que hayas comprendido algunos errores.

Todas las comparaciones ahora se realizan mediante ComparableVersion , que dice:

  • mezcla de '' - '' (guión) y '' . ''(punto) separadores,
  • la transición entre caracteres y dígitos también constituye un separador: 1.0alpha1 => [1, 0, alpha, 1]
  • Número ilimitado de componentes de la versión,
  • Los componentes de la versión en el texto pueden ser dígitos o cadenas,
  • las cadenas se verifican para calificadores conocidos y el ordenamiento calificador se usa para ordenar versiones. Los calificadores conocidos (no distinguen mayúsculas y minúsculas) son:
    • alpha o a
    • beta o b
    • milestone o m
    • rc o cr
    • snapshot
    • (la cuerda vacía) o ga o final
    • sp
  • Los calificadores desconocidos se consideran después de calificadores conocidos, con orden léxico (siempre sin distinción de mayúsculas y minúsculas),
  • un guión generalmente precede a un calificador, y siempre es menos importante que algo precedido por un punto.

Esto significa que las versiones salen en el siguiente orden, que creo que tiene mucho sentido, aparte de 1.0-SNAPSHOT justo en el medio:

  • 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

El principal problema que encontré en todo esto es que la snapshot viene después de la beta o rc , por lo que no puedes tener una versión de desarrollo de 1.0-SNAPSHOT , luego lanzar la versión 1.0-beta1 o 1.0-rc1 y hacer que Maven entienda que son posteriores.

También tenga en cuenta que 1.0-beta-1 es exactamente lo mismo que 1.0beta1 , y 1.0 es exactamente lo mismo que 1 o 1.0.0 .

Los rangos de versiones ahora también funcionan (casi) de la forma que usted esperaría. Por ejemplo, [1.0-alpha-SNAPSHOT,1.0] encontrará 1.0-beta1-SNAPSHOT , 1.0-beta1 , 1.0-rc1-SNAPSHOT , 1.0-rc1 , 1.0-SNAPSHOT o 1.0 , prefiriendo elementos posteriores a los anteriores. Esto es totalmente compatible con mvn versions:resolve , M2Eclipse y así sucesivamente.

Parece que Maven tiene la capacidad de indicar un rango de versiones como <version>[1.2.3,)</version> cómo Maven descubre qué es una versión más nueva o más antigua cuando no hay un esquema de control de versiones consistente que sea de código abierto. los paquetes siguen Por ejemplo

  • Junit 4.10
  • slf4j 1.7.2
  • Hibernate 4.1.7.Final
  • Primavera 3.1.2.RELEASE

¿Cómo calcula maven lo que es una versión anterior o una versión más nueva de un paquete en maven? ¿Qué pasa si el paquete utiliza letras como números de versiones a lo largo de las líneas de A, B, C o A2, A2, A4 ... etc.

¿Se supone que debe haber una forma oficial estándar de versión de paquetes en maven? ¿Los paquetes de código abierto comunes como Spring e hibernate ignoran esta convención de versiones?

Esta es una prueba que se escribió directamente contra la clase ComparableVersion de 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); } }

Esta prueba afirma que Maven considera que las siguientes versiones son de menor a mayor:

  • 1.0-beta1-SNAPSHOT
  • 1.0-beta1
  • 1.0-beta2-SNAPSHOT
  • 1.0-rc1-SNAPSHOT
  • 1.0-rc1
  • 1.0-SNAPSHOT
  • 1.0 y 1 (estos son iguales)
  • 1.0-sp
  • 1.0-lo que sea
  • 1.0.1

Según esta referencia , Maven requiere que la versión sea de la forma:

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

Donde MajorVersion , MinorVersion , IncrementalVersion y BuildNumber son numéricos y Qualifier es una cadena. Si su número de versión no coincide con este formato, entonces el número de versión completo se trata como el Calificador .

La referencia continúa y explica que puede "enfrentar problemas" (particularmente con los rangos de versión de Maven) si trabaja con artefactos que no siguen este esquema de versiones. Mirar el código fuente de Maven que está vinculado desde el artículo es muy útil.

De los ejemplos que has dado, los artefactos de Hibernate y Spring parecen desviarse en su uso de " . " En lugar de " - " para separar el calificador.

Algunos experimentos de mi parte muestran que DefaultArtifactVersion analizará los números de versión exactamente como se describió anteriormente. Es decir, el ejemplo de Spring dado ( 3.1.2.RELEASE ) se interpretará como:

  • Mayor: 0
  • Menor: 0
  • Incremental: 0
  • Calificador: 3.1.2.RELEASE

Más importante aún, la comparación de dos números de versión (si se usa Maven 3.0 o más reciente) es mucho más flexible. Los números de versión se dividen en listas de elementos (donde o . Marca el límite entre elementos, tenga en cuenta que . Tiene una prioridad más alta que - ). La comparación se lleva a cabo tomando cada artículo en términos y realizando una comparación de orden natural. Por 3.1.2.RELEASE tanto, 3.1.2.RELEASE se verá como más pequeño que 3.1.3.RELEASE . Las cadenas también se comparan, por 3.1.2.RELEASD tanto, 3.1.2.RELEASD se verá como más pequeño que 3.1.2.RELEASE . Hay algunas cadenas especiales que tienen equivalentes especiales, por ejemplo, 3.1.3.a.1 se ordenarán de la misma manera que 3.1.3.alpha.1

Sin embargo, mientras que la comparación es más flexible en las versiones más recientes de Maven. Los límites de rango de versión aún se evalúan utilizando el esquema Mayor: Menor: Incremental: Calificador, por lo que si está utilizando rangos de versión, la flexibilidad es menos útil.

Su suposición sobre el uso de mayor / menor / incremtal / etc. es simplemente errónea. La comparación se realiza en ComparableVersion que contiene la implementación. El ctor llamará a parseVersion(...) que usa ComparableVersion que se almacena como instancia en DefaultArtifactVersion y se usa durante el compareTo(..)

Hay partes como getMajor.. , etc. pero no funcionan correctamente. Esta es la razón por la cual será marcado en desuso .

La información de Stehpen Collony es válida para Maven 2, pero ya no para Maven 3.