experto desplegar cambiaron artefactos única

Question

que estoy usando Maven 2.2 con Nexus 1.4.0

Digamos que tengo una estructura pom así (con las versiones correspondientes)

parentproj, v1.0.1 
- childproj1, v1.0.2 
- childproj2, v1.0.7 

childproj1 y childproj2 representan diferentes partes de la aplicación (p. ej., gui y back-end) y deseo poder mantener sus versiones separadas para que pueda lanzar una nueva versión del backend sin tener que lanzar una nueva versión de la interfaz gráfica de usuario.

Ahora, para implementar esta estructura para Nexus sería conveniente para ir a parentproj y decir

mvn desplegar -DperformRelease = true

que desplegar todos los artefactos en el repositorio de Nexus realease . Esto funciona bien la primera vez que desplegarlo, pero la segunda vez que se encuentran con problemas: digamos que hice una actualización de childproj1 por lo que ahora tenemos las siguientes versiones:

parentproj, v1.0.1 
- childproj1, v1.0.3 
- childproj2, v1.0.7 

En esta situación Nexus no lo hará permítanme implementar mvn desde parentproj, ya que ya tiene una copia de childproj2 en la versión 1.0.7. Nexus dirá "Recurso, solicitud ilegal: Repositorio con ID = 'lanzamientos' no permite la actualización de artefactos". Esto está bien, no quiero actualizar las versiones existentes por error.

Pero supongo que lo que me gustaría hacer es poder decirle a maven algo así como "implementar solo los artefactos que tienen versiones que no están ya presentes en el repositorio de versiones".

¿Hay alguna manera de hacerlo, o tendré que implementar cada proyecto por sí mismo?

Answer 1

En mi experiencia, ha sido más fácil implementar todo y, a menudo, utilizar el mismo número de versión para todos los componentes. Por ejemplo, si mi equipo está trabajando en la versión 1.0.7, todos los submódulos tienen el número de versión de 1.0.7-SNAPSHOT, hasta que lo liberemos, aunque no haya cambiado el código en ciertos módulos. Luego, cuando implementemos, desplegaríamos toda la aplicación. Creo que tiene varias ventajas sobre una implementación por partes. En primer lugar, si cada uno tiene que retroceder a la última versión estable, solo tiene que volver a la versión 1.0.6 para todos los módulos; no debe recordar que el backend era 1.0.3 mientras que la GUI era 1.0.6. En segundo lugar, garantiza que todos los componentes se compilan correctamente entre sí y se han probado como un grupo lógico.

siento, sé que esto no es una respuesta concreta a su pregunta, pero, al menos en el caso de mi equipo, que era útil pensar un poco diferente

Answer 2

sugeriría que si va a mantener, construir y despliegue los módulos de forma independiente, debe considerar configurar trabajos de CI y mvn deploy separados para cada uno. Tener puestos de trabajo independientes mvn deploy le dará el comportamiento que está buscando fuera de la caja. Esto significa no usar el agregador pom (parentprj) para intentar construir e implementar estos módulos.

Si desea hacer todo lo posible desde el agregador pom, como compilar e implementar, le sugiero que siga la respuesta de John y mantenga todo el número de versión sincronizado.

Depende de cómo su equipo quiera ver el código base.Si quieres mantener las cosas en una verdadera forma modular, deberías utilizar tus módulos maven como bloques de construcción, tratándolos de manera diferente, hasta que estés listo para armar toda la aplicación. Si su aplicación es de naturaleza más monolítica, trátela como tal y mantenga las cosas sincronizadas. Esto no significa que aún no pueda dividir módulos Maven separados para mantener la modularidad de la base de códigos, solo reconozca que no tienen ningún valor fuera del contexto de su aplicación más grande.

Una buena forma de tomar esta decisión es preguntarse "¿Algún otro proyecto/aplicación deberá hacer referencia a este módulo como una dependencia?". De ser así, es una buena práctica construirlo, versionarlo e implementarlo de manera independiente. Si no, no veo ningún inconveniente para hacer que las versiones coincidan.

Answer 3

En primer lugar, creo que debe distinguir entre proyecto principal y proyecto de agregación. Los proyectos principales deben usarse para aquellas configuraciones que son comunes a varios proyectos, p. versiones de dependencias; los proyectos de agregación deben usarse para construir al mismo tiempo un grupo de proyectos, p. un conjunto de frascos y la guerra que los incluye.

Los dos tipos de proyectos se mantienen mejor separados. El proyecto principal generalmente no cambia muy a menudo y, cuando lo hace, generalmente es mejor lanzar nuevas versiones de todos los proyectos que dependen de él; el único propósito del proyecto de agregación es impulsar la compilación de un grupo de proyectos, por lo que su número de versión probablemente debería cambiar cada vez que uno de los proyectos que contiene deba ser liberado.

Una vez que haya separado el padre del agregador, se encuentra en una mejor posición para elegir si seguir los consejos de John Paulett y mantener todo en el mismo número de versión o intentar cambiar el número de versión de cada proyecto solo cuando realmente necesite liberarlo. La primera opción es más simple y menos propensa a errores, pero hace que se libere una nueva versión de las bibliotecas que no han cambiado. Esto podría no ser aceptable si, por ejemplo, necesita enviar parches en lugar de versiones completas. La segunda opción es más complicada y propensa a errores, pero hace que sus números de versión coincidan con la evolución de su software. El complemento de lanzamiento de Maven y la herramienta de integración continua de Jenkins pueden ser de ayuda allí, creo que deberías consultarlos. Además, vea si puede actualizar Maven a al menos la versión 2.2.1 y Nexus a una versión más reciente.

Answer 4

Claramente, esta necesidad no es tratada por maven, ni por Nexus ni por archiva. Por ahora, solo se puede abordar mediante trucos adicionales configurados por el administrador de compilación como los sugeridos en publicaciones anteriores.

En un mundo ideal

• el pom incluiría
  . tanto la versión de lanzamiento como la versión de instantánea del módulo
  . una definición de los archivos que, si se modifican, justifican el uso de la versión de instantánea
  . el sistema de gestión de control de fuente de referencia del módulo lanzado
  

• módulos dependientes poms añadirían en la sección de la dependencia apropiada la información de versión de lanzamiento junto a la información de la versión instantánea para que se enlaza a la biblioteca instantánea si está presente en el repositorio y la biblioteca de la liberación de otro modo
  

• el reactor experto tendría la opción de leer tanto la jerarquía de la dependencia y el archivo cambia de información (esta SCM) para saber si un determinado módulo se va a utilizar en su versión de lanzamiento o una instantánea .

• El complemento de publicación saltaría de forma predeterminada la liberación de los módulos que aún se pueden usar con su versión de lanzamiento en función de los cambios de archivo y la información de dependencia.