2012-06-07 17 views
5

Tengo un pom principal para toda la compañía con una sección <dependencyManagement> que define las versiones de mis proyectos que deberían usarse en mi aplicación, algunas de las cuales son SNAPSHOT, un poco como esta:Maven Release Plugin no actualiza SNAPSHOTs en dependencyManagement

<dependencyManagement> 
    <dependencies> 
    ... 
    <dependency> 
     <groupId>my.group</groupId> 
     <artifactId>myArtifact</artifactId> 
     <version>1.0-SNAPSHOT</version> 
    </dependency> 
    ... 
    <dependencies> 
</dependencyManagement> 

Cuando corro release:prepare en el pom padres, estas instantáneas no se quitan. El resultado es que los proyectos que heredan de los padres no pueden usar sus versiones cuando se lanzan ellos mismos. ¿Cómo me aseguro de que la sección <dependencyManagement> del pom padre se actualice cuando lance?

Vi esta pregunta: why does maven release plugin allow for SNAPSHOT version in dependency managment?, pero los tickets mencionados afirman que se corrigió en versiones anteriores del complemento.

Maven Release Plugin 2.3.1 
Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+0000) 
Java version: 1.6.0_31, vendor: Sun Microsystems Inc. 
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" 
+0

¿La dependencia dada es parte de su reactor? – khmarbaise

+0

No, en este caso no es así. El padre pom no tiene ningún módulo declarado en él, ya que se usa en varios proyectos diferentes. La idea es centralizar cosas que son comunes a todos nuestros proyectos, como repositorios, metadatos, etc. ¿Eso hace la diferencia? – Conan

+0

Entonces, ¿cuál es tu problema real? - ¿No puedes lanzar tu propio proyecto? - ¿Desea que la instantánea de la tira del complemento aparezca mencionada en JIRA? –

Respuesta

1

El maven-release-plugin solo se preocupa de comprobar si tiene SNAPSHOT -s en su sección <dependencies/>. El <dependencies/> será heredado por todos los módulos que extiendan este elemento primario. Siempre tratarán de resolver estas dependencias antes de construir.

La diferencia entre las secciones <dependencies/> y <dependencyManagement/> es que esta última solo define las versiones que se utilizarán. Dicho esto, el complemento de publicación no le preocupa en absoluto si ha definido SNAPSHOT-s allí, a menos que este proyecto principal sea un agregador o parte de un agregador y este elemento principal se está lanzando como un todo con el agregador.

Del mismo modo, el complemento maven-release-no se ocupa de <pluginManagement/>. Además, creo que solo se dirige a las propiedades de Maven que contienen versiones de artefactos solo cuando están relacionadas con <dependencies/>.

La peor parte es que, por lo que recuerdo, ni siquiera se le advertirá si una dependencia/complemento tiene una versión SNAPSHOT, si está en una sección <*Management/>.

Por esta razón, el enfoque al que he recurrido es tener un POM principal con <properties/> que contenga las versiones de los artefactos. Antes de soltarlo, lo escaneo para SNAPSHOT -s usando grep:

grep SNAPSHOT pom.xml 
+0

Realmente tengo las versiones definidas en '' en el pom padre, que luego se referencian en la sección ''. Esperaba definir todas las versiones de nuestros proyectos internos en un solo pom como SNAPSHOTs, y mantener todas las versiones fuera de nuestros varios poms del proyecto. Sin embargo, eso depende de que el padre pom especifique las versiones de lanzamiento en dependencyManagement, así que supongo que esto no funcionará. Supongo que tendré que mover la información de la versión a cada proyecto diferente, lo cual es una lástima. Quiero evitar tener que cambiar manualmente las versiones como parte del proceso de lanzamiento. – Conan

+1

Lo que me sorprende de esto es que cuando lanzo un proyecto en particular que está heredando versiones de la sección '' del padre, no se queja de las SNAPSHOT. Parece que si las versiones no se mencionan en los poms que se lanzan, entonces el complemento de lanzamiento simplemente les permite ir en lugar de solicitar eliminar las SNAPSHOT. – Conan

+1

Me entristece que '' se comporte de esta manera, pero parece ser por diseño, entonces estoy aceptando esta respuesta. ¡Gracias por tus comentarios! – Conan

1

¿Está intentando liberar artefactos que no forman parte de la construcción que está preparando? Si realiza una actualización: realice, ¿qué artefactos debería cargar el complemento al repositorio si no existen? (Si lo hacen, ¿por qué colocas la versión instantánea?).
Creo que como dijo @khmarbaise, el complemento no eliminará SNAPSHOTS que no sean parte de su reactor (el complemento puede pensar que son dependencias de terceros).

Esto es un comentario, lo puse como respuesta porque no tengo reputación para publicar comentarios todavía ... ¡y lo siento por mi inglés!

+0

Sí, en este escenario, estoy lanzando solo un artefacto para padres, con el paquete 'pom'. El único artefacto que espero que se cargue en este momento es el padre pom. Cuando se trata de liberar realmente un proyecto particular que contiene código, heredará del padre liberado y, por lo tanto, usará las versiones definidas en su sección ''; si contienen SNAPSHOT, entonces mi versión está en un estado dudoso en el que no puedo confiar en que sea reutilizable en el futuro. – Conan

+0

PD su inglés es excelente: D – Conan

+0

Como solución alternativa, si el propósito de la versión es simplemente reemplazar SNAPSHOT en dependencyManagement y comprometerse con SCM debe intentar hacer solo ese proceso manualmente (o mejor hacer un proceso por lotes), no cambie manualmente las versiones de cada proyecto, vamos don don !. Pruebe algo como esto (en un archivo .bat): sed -i 's/-SNAPSHOT // g' pom.xml; cvs commit pom.xml. Puede usar GnuWin para la funcionalidad sed, o mejor, ¡comience a usar linux! –

Cuestiones relacionadas