Pregunta ¿Cómo le digo a Maven que use la última versión de una dependencia?


En Maven, las dependencias generalmente se configuran así:

<dependency>
  <groupId>wonderful-inc</groupId>
  <artifactId>dream-library</artifactId>
  <version>1.2.3</version>
</dependency>

Ahora, si está trabajando con bibliotecas que tienen lanzamientos frecuentes, actualizar constantemente la etiqueta <version> puede ser algo molesto. ¿Hay alguna manera de decirle a Maven que use siempre la última versión disponible (del repositorio)?


653
2017-08-27 16:17


origen


Respuestas:


NOTA: 

¡Esta respuesta se aplica solo a Maven 2! El mencionado LATEST y RELEASE metaversions han sido eliminados en Maven 3 "por compilaciones reproducibles", hace más de 6 años. Por favor refiérase a esto Solución compatible con Maven 3


645
2017-07-23 14:58



Ahora sé que este tema es antiguo, pero al leer la pregunta y la respuesta proporcionada por OP parece que Complemento de versiones Maven podría haber sido realmente una mejor respuesta a su pregunta:

En particular, los siguientes objetivos podrían ser de utilidad:

  • versiones: use-latest-versions busca en el pom todas las versiones que han sido una versión más nueva y los reemplaza con la última versión.
  • versiones: use-latest-releases busca en el pom todo lo que no sea SNAPSHOT versiones que han sido más nuevas liberar y los reemplaza con el última versión de lanzamiento.
  • versiones: propiedades de actualización propiedades de actualizaciones definidas en una proyecto para que correspondan a la última versión disponible de dependencias específicas. Esto puede ser útil si un conjunto de dependencias todos deben estar bloqueados en una versión.

Los siguientes otros objetivos también se proporcionan:

  • versiones: display-dependency-updates escanea las dependencias de un proyecto y produce un informe de aquellos dependencias que tienen más nuevo versiones disponibles.
  • versiones: display-plugin-updates escanea los complementos de un proyecto y produce un informe de esos complementos que tienen versiones más nuevas disponibles.
  • versiones: update-parent actualiza la sección principal de un proyecto para que hace referencia a los más nuevos versión disponible. Por ejemplo, si usted usa un POM raíz corporativo, esto objetivo puede ser útil si necesita asegúrese de estar usando la última versión de la raíz corporativa POM.
  • versiones: update-child-modules actualiza la sección principal de módulos secundarios de un proyecto por lo que el versión coincide con la versión de Proyecto actual. Por ejemplo, si tener un pom del agregador que también el padre de los proyectos que agregados y los niños y las versiones principales no se sincronizan, esto mojo puede ayudar a arreglar las versiones de módulos secundarios (Tenga en cuenta que puede necesitar invocar Maven con la opción -N en Para ejecutar este objetivo si su proyecto está roto tan mal que no se puede construir debido a la versión desajuste).
  • versiones: instantáneas de bloqueo busca en el pom todo -SNAPSHOT versiones y los reemplaza con el la versión actual de la marca de tiempo de -SNAPSHOT, p. -20090327.172306-4
  • versiones: desbloquear-instantáneas busca en el pom toda la marca de tiempo versiones de instantáneas bloqueadas y reemplaza ellos con -SNAPSHOT.
  • versiones: rangos de resolución encuentra dependencias usando rangos de versión y resuelve el rango al específico versión en uso
  • versiones: use-releases busca en el pom todas las versiones -SNAPSHOT que han sido liberados y reemplazan ellos con la publicación correspondiente versión.
  • versiones: use-next-releases busca en el pom todo lo que no sea SNAPSHOT versiones que han sido más nuevas liberar y los reemplaza con el próxima versión de lanzamiento.
  • versiones: use-next-versions busca en el pom todas las versiones que han sido una versión más nueva y los reemplaza con la próxima versión.
  • versiones: commit elimina los archivos pom.xml.versionsBackup. Formularios la mitad de la incorporada "Poor Man's SCM ".
  • versiones: revertir restaura los archivos pom.xml de pom.xml.versionsBackup archivos. Formularios la mitad de la incorporada "Poor Man's SCM ".

Solo pensé en incluirlo para futuras referencias.


312
2017-07-23 16:03



Por favor, eche un vistazo a esta página (sección "Rangos de versión de dependencias"). Lo que quizás quieras hacer es algo así como

<version>[1.2.3,)</version>

Estos rangos de versión se implementan en Maven2.


162
2017-08-27 16:56



A diferencia de otros, creo que hay muchas razones por las que podrías siempre quiero la última versión. Particularmente si está realizando una implementación continua (a veces tenemos 5 versiones en un día) y no desea hacer un proyecto de varios módulos.

Lo que hago es hacer que Hudson / Jenkins haga lo siguiente para cada compilación:

mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true

Es decir, uso el plugin de versiones y el plugin scm para actualizar las dependencias y luego verificarlo en el control de fuente. Sí, dejé que mi CI hiciera comprobaciones de SCM (que debes hacer de todos modos para el complemento de lanzamiento maven).

Deberá configurar el complemento de versiones para que solo actualice lo que desea:

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>1.2</version>
            <configuration>
                <includesList>com.snaphop</includesList>
                <generateBackupPoms>false</generateBackupPoms>
                <allowSnapshots>true</allowSnapshots>
            </configuration>
        </plugin>

Utilizo el complemento de lanzamiento para hacer el lanzamiento que se ocupa de -SNAPSHOT y valida que hay una versión de lanzamiento de -SNAPSHOT (que es importante).

Si haces lo que hago, obtendrás la última versión para todas las compilaciones de instantáneas y la última versión de lanzamiento para compilaciones de versiones. Tus compilaciones también serán reproducibles.

Actualizar

Observé algunos comentarios que me preguntaron algunos detalles de este flujo de trabajo. Diré que ya no usamos este método y la gran razón por la cual el plugin de versiones de maven es defectuoso y, en general, es inherentemente defectuoso.

Es defectuoso porque para ejecutar el plugin de versiones para ajustar versiones, todas las versiones existentes deben existir para que el pom se ejecute correctamente. Ese es el plugin de versiones que no puede actualizarse a la última versión de nada si no puede encontrar la versión a la que se hace referencia en el pom. En realidad, esto es bastante molesto ya que a menudo limpiamos versiones antiguas por motivos de espacio en disco.

Realmente necesitas una herramienta separada de maven para ajustar las versiones (para que no dependas del archivo pom para ejecutarse correctamente). He escrito una herramienta de este tipo en el lenguaje humilde que es Bash. La secuencia de comandos actualizará las versiones como el complemento de la versión y verificará que el pom vuelva al control de la fuente. También se ejecuta como 100 veces más rápido que el complemento de versiones mvn. Desafortunadamente no está escrito de manera pública, pero si las personas están interesadas, podría hacerlo y ponerlo en una esencia o github.

Volviendo al flujo de trabajo, ya que se realizaron algunos comentarios acerca de que esto es lo que hacemos:

  1. Tenemos 20 o más proyectos en sus propios repositorios con sus propios trabajos jenkins
  2. Cuando lanzamos el complemento de lanzamiento Maven se utiliza. El flujo de trabajo de eso está cubierto en la documentación del complemento. El plugin de lanzamiento maven es una mierda (y estoy siendo amable) pero funciona. Algún día planeamos reemplazar este método con algo más óptimo.
  3. Cuando se libera uno de los proyectos, jenkins ejecuta un trabajo especial que llamaremos el trabajo de actualización de todas las versiones (cómo Jenkins sabe que su lanzamiento es complicado, en parte porque el complemento de lanzamiento de maven jenkins también es malo).
  4. La actualización de todas las versiones del trabajo sabe sobre los 20 proyectos. En realidad, es un agregador pom para ser específico con todos los proyectos en la sección de módulos en orden de dependencia. Jenkins ejecuta nuestro magic groovy / bash foo que hará que todos los proyectos actualicen las versiones a la última versión y luego se registren en los poms (de nuevo en orden de dependencia según la sección de módulos).
  5. Para cada proyecto si el pom ha cambiado (debido a un cambio de versión en alguna dependencia) se registra y luego hacemos ping a jenkins para que ejecute el trabajo correspondiente para ese proyecto (esto es para preservar el orden de dependencia de la compilación, de lo contrario estarás a merced del programador de encuestas SCM).

En este punto, soy de la opinión de que es bueno tener el lanzamiento y la versión automática como una herramienta separada de tu construcción general de todos modos.

Ahora puedes pensar que maven es una mierda debido a los problemas mencionados anteriormente, pero esto en realidad sería bastante difícil con una herramienta de compilación que no tenga un declarativo fácil de analizar extensible sintaxis (también conocida como XML).

De hecho, agregamos atributos XML personalizados a través de los espacios de nombres para ayudar a insinuar los scripts de bash / groovy (por ejemplo, no actualizar esta versión).


72
2018-01-09 21:21



La sintaxis de dependencias se encuentra en el Especificación de requisito de versión de dependencia documentación. Aquí está para completar:

Dependencias version elemento define los requisitos de versión, utilizados para calcular la versión de dependencia efectiva. Los requisitos de versión tienen la siguiente sintaxis:

  • 1.0: Requisito "suave" en 1.0 (solo una recomendación, si coincide con todos los demás rangos para la dependencia)
  • [1.0]: Requisito "difícil" en 1.0
  • (,1.0]: x <= 1.0
  • [1.2,1.3]: 1.2 <= x <= 1.3
  • [1.0,2.0): 1.0 <= x <2.0
  • [1.5,): x> = 1.5
  • (,1.0],[1.2,): x <= 1.0 o x> = 1.2; varios conjuntos están separados por comas
  • (,1.1),(1.1,): esto excluye 1.1 (por ejemplo, si se sabe que no   trabajar en combinación con esta biblioteca)

En tu caso, podrías hacer algo como <version>[1.2.3,)</version>


27
2017-07-22 16:21



¿Posiblemente dependa de las versiones de desarrollo que obviamente cambian mucho durante el desarrollo?

En lugar de incrementar la versión de las versiones de desarrollo, puede usar una versión de instantánea que sobrescriba cuando sea necesario, lo que significa que no tendrá que cambiar la etiqueta de la versión en cada cambio menor. Algo así como 1.0-SNAPSHOT ...

Pero tal vez estás tratando de lograr algo más;)


14
2017-08-27 16:30



Quien esté usando ÚLTIMA VEZ, asegúrese de tener -U de lo contrario, no se extraerá la última instantánea.

mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST
// pull the latest snapshot for my-foo from all repositories

6
2017-08-03 08:38



En el momento en que se planteó esta pregunta, hubo algunos problemas con los rangos de versión en maven, pero estos se han resuelto en las versiones más nuevas de maven. Este artículo capta muy bien cómo funcionan los rangos de versión y las mejores prácticas para comprender mejor cómo maven entiende las versiones: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855


5
2018-04-03 16:00



La verdad es que incluso en 3.x todavía funciona, sorprendentemente los proyectos se construyen y despliegan. Pero la palabra clave MÁS RECIENTE / LIBERACIÓN causa problemas en m2e y eclipse por todas partes, TAMBIÉN los proyectos dependen de la dependencia que se implementó a través de la ÚLTIMA / LIBERACIÓN no reconoce la versión.

También causará problemas si intenta definir la versión como propiedad, y lo referenciará en donde.

Entonces la conclusión es usar el versiones-maven-plugin si puedes.


3
2018-06-26 15:53



A veces no quiere usar rangos de versión, porque parece que son "lentos" para resolver sus dependencias, especialmente cuando hay una entrega continua en el lugar y hay toneladas de versiones, principalmente durante el desarrollo intenso.

Una solución sería usar el versiones-maven-plugin. Por ejemplo, puede declarar una propiedad:

<properties>
    <myname.version>1.1.1</myname.version>
</properties>

y agrega las versiones-maven-plugin a tu archivo pom:

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <properties>
                    <property>
                        <name>myname.version</name>
                        <dependencies>
                            <dependency>
                                <groupId>group-id</groupId>
                                <artifactId>artifact-id</artifactId>
                                <version>latest</version>
                            </dependency>
                        </dependencies>
                    </property>
                </properties>
            </configuration>
        </plugin>
    </plugins>
</build>

Luego, para actualizar la dependencia, debe ejecutar los objetivos:

mvn versions:update-properties validate

Si hay una versión más nueva que la 1.1.1, le dirá:

[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2

2
2018-05-08 15:59



Si quieres que Maven use la última versión de una dependencia, entonces puedes usar Versiones Maven Plugin y cómo usar este complemento, Tim ya ha dado una buena respuesta, sigue su responder.

Pero como desarrollador, no recomendaré este tipo de prácticas. ¿POR QUÉ?

respuesta a por qué ya está dado por Pascal Thivent en el comentario de la pregunta

Realmente no recomiendo esta práctica (ni el uso de rangos de versión) para   en aras de la reproducibilidad de la construcción. Una construcción que comienza de repente   fallar por una razón desconocida es mucho más molesto que actualizar manualmente   un número de versión.

Recomendaré este tipo de práctica:

<properties>
    <spring.version>3.1.2.RELEASE</spring.version>
</properties>

<dependencies>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>

</dependencies>

es fácil de mantener y fácil de depurar. Puedes actualizar tu POM en poco tiempo.


0
2018-04-18 09:10