2012-05-10 10 views
12

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 ejemplo versions: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 ejemplo versions: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.

Respuesta

5

El problema simple que tiene es que su padre tiene un número de versión diferente al de su hijo, lo cual es una forma incorrecta para una compilación de módulo múltiple. Se pretende que una compilación de varios módulos tenga una cantidad de módulos relacionados que tengan el mismo proceso de liberación del cual se obtiene el mismo número de versión. Si sigues esa guía, no necesitas el plugin de versiones, solo haces la publicación a través de la versión: prepare and release: perform That's it.

Actualización: Después de la discusión adicional sugeriría a configurar un nuevo conjunto de puestos de trabajo de Hudson que contienen las dependencias entre los módulos (/ deps aguas arriba aguas abajo.) Y hacer un lanzamiento en cada trabajo de Hudson, que desencadena la próxima en la cadena de trabajos, etc. Estos requisitos previos para tener módulos separados y áreas separadas en el control de versión también. De lo contrario, esta pelea se perderá con Maven y complicará la vida.

+3

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". –

+0

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

+0

_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'. –

Cuestiones relacionadas