Sería genial si la comunidad de Maven guru me puede ayudar con la siguiente tarea.Completamente automatizar el procedimiento de liberación con versiones + versiones plugins
Me gustaría automatizar el proceso de lanzamiento del módulo Maven en Hudson de forma tal que el proceso de lanzamiento se ejecute en modo batch (no necesita nada de la consola). Actualmente utilizo los pasos comunes release:prepare
(con <preparationGoals>versions:update-parent clean verify</preparationGoals>
para actualizar el padre a la última versión antes del commit) + release:perform
. Sin embargo, me gustaría Maven para hacer lo siguiente:
en algún tiempo durante la etapa de preparación:
- Para todas las dependencias que se ajustan a la
groupId
de la corriente del módulo y el padre, reemplace-SNAPSHOT
con versión de lanzamiento (por ejemploversions:use-releases -Dincludes=???
) .
en algún tiempo después de la liberación:
- Para todas las dependencias que se ajustan a la
groupId
de la corriente del módulo y el padre , reemplace versión con-SNAPSHOT
versión (por ejemploversions:use-latest-snapshots ...
).
Ejemplo:
<parent>
<groupId>org.mycompany.myproject</groupId>
<artifactId>myproject-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>myproject-api</artifactId>
<version>1.1-SNAPSHOT</version>
</dependency>
antes del módulo está etiquetado se transforma en:
<parent>
<groupId>org.mycompany.myproject</groupId>
<artifactId>myproject-parent</artifactId>
<version>1.0</version>
</parent>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>myproject-api</artifactId>
<version>1.1</version>
</dependency>
y después de la liberación se logró se transforma en:
<parent>
<groupId>org.mycompany.myproject</groupId>
<artifactId>myproject-parent</artifactId>
<version>1.1-SNAPSHOT</version>
</parent>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>myproject-api</artifactId>
<version>1.2-SNAPSHOT</version>
</dependency>
me da la gana necesita una mezcla de
versions:use-releases scm:commit release:prepare release:perform versions:use-latest-snapshots scm:commit
pero no estoy seguro de cuál es la mejor manera de hacerlo. Especialmente sería bueno tener el menor compromiso posible: la dificultad es que reparationGoals
se ejecuta después de la verificación de la versión -SNAPSHOT
.
El proyecto descrito no es un proyecto de varios módulos en el sentido de que el POM padre no está remitiendo a sus hijos a través del <modules>
. SMC estructura es la siguiente:
.
|
+-- myproject-parent
| +-- pom.xml
+-- myproject-api
| +-- pom.xml
+-- myproject-impl
+-- pom.xml
Las dependencias son: los padres
myproject-api → myproject-parent
myproject-impl → myproject-parent
myproject-impl → myproject-api
del proyecto POM (myproject-parent
) se dará a conocer en raras ocasiones y por lo tanto será lanzado por primera vez. Luego, myproject-api
(si es necesario) y luego myproject-impl
.
No puedo estar de acuerdo contigo. Tenemos una estructura de módulo plana: esta es la única manera de hacer que se dividan e independicen en Hudson (de lo contrario, la falla de prueba en el submódulo falla todo el proyecto). Algunos de los módulos (por ejemplo, el POM principal) rara vez se modifican: no es necesario liberarlos. Otros (como "modelo") se lanzarán pocas veces. Y su consejo no funciona si tengo dependencias entre dos proyectos de varios módulos. Además, incluso para la creación de varios módulos, no tengo pruebas de que 'release: prepare' reemplace las dependencias' -SNAPSHOT' con versiones de "versión futura". –
Por la primera vez que puedo decir que es bueno si las pruebas fallan, la construcción completa fallará porque algo está mal. La pregunta es por qué te gusta separarlos en Hudson? O bien esta es una compilación de varios módulos o no lo es. Además, si el padre pom se cambia raramente, entonces suena que podría ser un módulo separado que tiene su propio ciclo de lanzamiento y necesita liberarlo porque otros lo usa como una dependencia/padre. Si tiene dependencias entre los módulos, lo que funcionará perfecto en una compilación de varios módulos. Puedo recomendar echar un vistazo aquí: https://github.com/khmarbaise/javaee como ejemplo. – khmarbaise
_Para la primera vez que puedo decir que es bueno si las pruebas fallan, la compilación fallará porque algo está mal. No siempre es útil. En nuestro proyecto, pequeños grupos de desarrolladores trabajan en su propio módulo. Cada módulo tiene su propia lista de notificaciones por correo electrónico para enviar correos electrónicos cuando la construcción falla/recuperarse de una falla. Por lo tanto, las personas 'X' y' Y' son responsables de los módulos 'A' y' B'. –