6

Actualmente estoy trabajando en la optimización de una versión maven de un proyecto maven de varios módulos. El proyecto consiste en aproximadamente 90 módulos de Maven. En general, hay algunas librerías transversales que conforman el núcleo y luego hay alrededor de 15 "módulos de aplicación" que componen toda la aplicación (que luego se despliega como en una GUERRA)¿Crear un maven de múltiples módulos y liberar módulos individuales de forma independiente?

Ahora, en general, todo el proyecto tiene una versión principal "2.5" así que cuando se realiza una nueva versión principal, todos los "módulos de aplicación" tienen la misma versión "2.5.0". Hasta aquí todo bien.

Si un módulo tiene un error que debe corregirse o necesita mejorar, se debe lanzar una nueva versión de ese "módulo de aplicación". Entonces, por ejemplo, el Módulo A tiene un error solucionado, entonces A.jar debería estar en la versión "2.5.1", mientras que el resto debería ser "2.5.0".

padre (2.5.0-SNAPSHOT - Módulo A (2.5.1-SNAPSHOT) - Módulo B (2.5.0-SNAPSHOT) - Módulo C (2.5.2-SNAPSHOT) - War (2.5. 3-SNAPSHOT) < - 3 al final, porque C tuvo 2 relanzamientos y A uno y se lanzó después de cada lanzamiento del módulo por simplicidad

Nos decidimos por gestionar las versiones de artefactos en el pom maestro para que nos pongamos No es necesario actualizar las versiones de dependencia de cada artefacto después de liberar un módulo.

Así que ahora cada vez que esté listo un "módulo de aplicación" actualizado, usamos el maven lanzar el complemento para llevar a cabo la publicación de ese módulo (Estamos lanzando un módulo, no todo el proyecto). Entonces, digamos que estamos liberando el Módulo A en la versión 2.5.4, lo que resulta en que A.jar se implemente como versión 2.5.4 y termine actualizando el código del módulo a 2.5.5-SNAPSHOT.

Una vez hecho esto, debemos actualizar la versión en el pom maestro, por lo que todos los módulos continúan haciendo referencia a la versión correcta.

Gracias a la sección DependencyManagement del pom del maestro, si construyo el módulo de Guerra, se selecciona automáticamente la nueva versión del módulo A.

Ahora viene la parte difícil: Tan pronto como todos los módulos son liberados, Se debe lanzar una nueva versión de la aplicación web. Esto debería contener todos los Módulos sin modificar, así como los que acabamos de lanzar. Actualmente estoy luchando sobre cómo hacer eso. Si dependo de la versión padre poms, el lanzamiento contendría versiones de SNAPSHOT (todas las versiones de una versión son demasiado altas), lo que no puedo permitir con el complemento de la versión.

¿Cuál sería la mejor solución para este dilema?

Tuve una idea para convertir la gestión de dependencias en un pom independiente, que luego se importa a la gestión de dependencia poms maestra utilizando el ámbito de "importación".

¿Es este tipo de szenario una idea estúpida? ¿Hay alternativas para desarrollar y mantener una gran aplicación de múltiples módulos como esta? Simplemente tener todas las versiones sincronizadas y usar el complemento de lanzamiento en todo el proyecto no es una opción ya que la aplicación es grande y las aplicaciones del cliente tienen que cargar versiones de módulos actualizadas. Algunos de nuestros clientes tienen conexiones realmente lentas, por lo que desplegar todos los módulos cada vez los haría realmente infelices.

Ayuda muy apreciada,

Chris

Respuesta

1

Bueno, se me ocurrió una solución para mi problema. Es una mezcla de un pequeño parche de complemento de liberación y un plugin de Jenkins para manejar la configuración de línea de comandos bastante intensa que se necesita.

Descripción del proceso de lanzamiento: https://dev.c-ware.de/confluence/display/PUBLIC/Releasing+modules+of+a+multi-module+project+with+independent+version+numbers

Descripción de la Jenkins Plugin: https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin

Código del plugin: https://github.com/chrisdutz/jenkins-release-plugin

2

En primer lugar, es importante darse cuenta de que los números de versión, si bien son importantes para la gestión de la dependencia, son completamente arbitraria. Al menos, la forma del número de versión es arbitraria (sí, estoy al tanto de the syntax for Maven version ranges, que nunca he escuchado que alguien use). Algunos proyectos OSS evitan por completo los números de versión "tradicionales" y solo usan versiones de repositorio SVN o fechas para el control de versiones.

Una opción es no tener una versión "en todo el proyecto" y permitir que cada uno de sus componentes tenga diferentes números de versión. Siento que esta es una solución completamente aceptable.

Otra solución es liberar usando dependencias de instantáneas. No se "supone" que hagas esto, pero nada te impide codificar la versión de la instantánea (que es increíblemente prolijo y con marca de tiempo). Nada, excepto el espectro de compilaciones irrepetibles, de todos modos.

Si debe tener todos los componentes con el mismo número de versión, le sugiero que incorpore un número de compilación en el componente secundario de la versión de su proyecto.

En este enfoque, aprovecha el Maven Build Number plugin para distinguir las versiones incrementales dentro de una versión como se describe en esta pregunta: Can I set the project version with a buildnumber-maven-plugin?.

Tenga en cuenta que solo lo haría en un perfil de "versión final" que solo utiliza su servidor de compilación (o su ingeniero de compilación).

Version Numbers plugin es también tu amigo aquí.

El flujo de trabajo versión final sería algo así como lo siguiente:

  1. de inicio con la versión 2.5.5-SNAPSHOT.
  2. mvn versions:set -DnewVersion 2.5.5.
  3. Commita y etiquete su versión (o cree una rama, cualquiera que sea su estrategia).
  4. mvn deploy -Prelease que activa su "perfil de publicación" que agrega el número de compilación al artefacto finalName.
  5. mvn versions:set -DnewVersion 2.5.5-SNAPSHOT.
  6. Confirme su versión "posterior a la publicación".

Incremente a la versión 2.5.6, 2.6.0 etc. cuando tenga una versión verdaderamente "importante".

¡Buena suerte!

+0

Hola noahz, Gracias por la explicación que ayudó. Me di cuenta de que esto funcionaría si mis módulos no tuvieran dependencias entre ellos. Desafortunadamente lo hacen. Tenía otra idea de cómo podría resolverse este problema y creé una nueva respuesta con él (Puede escribir más texto de esa manera ;-)) –

0

Anoche me di cuenta de que la compilación que escuché en mi pregunta tenía otro problema importante: los módulos tienen diferencias entre sí y estos no serían manejados por el complemento de lanzamiento. Estas dependencias SNAPSHOT harían que el complemento fallara (lo cual es bueno).

Así que tuve otra idea que podría resolver mis problemas: Crearía dos artefactos de maven pom "versions-dev" y "versions-rel" que contienen una sección de gestión de dependencias que define las versiones dev y rel. En mi maestro pom ahora crearía dos perfiles "desarrollo" (activo por defecto) y "lanzamiento" que debe ser activado manualmente.Estos perfiles contienen una sección de gestión de dependencias y cada uno importa la gestión de dependencias de la correspondiente versión-pom artefacto utilizando el alcance "importación".

Ahora, para una versión, tendría que hacer los siguientes pasos: - Actualizar las versiones-rel y versiones-dev a las nuevas versiones. - Comprometerse - Tag - ejecutar la liberación: realizar la meta de la liberación de plugins

Todavía hay una cosa que podría causar problemas: Suponiendo que todos los módulos han sido modificados, pero sólo una de ellas deberían incluirse en una nueva versión, entonces este enfoque también volvería a implementar todos los módulos, incluso los que no quería lanzar. Esto provocaría que las versiones modificadas se implementaran con la misma versión que las versiones publicadas anteriormente. Ahora podría evitar esto al no lanzar el proyecto principal, sino solo los módulos individuales. Sin embargo, si fuera posible implementar solo aquellas versiones que aún no están implementadas, el proceso de liberación sería mucho más fácil.

¿Alguna sugerencia, objeción, cosas que perdono?

Chris

+0

"Crearía dos artefactos de maven pom" versiones-dev "y" versions-rel "que contiene una sección de gestión de dependencias que define las versiones dev y rel ". - ¿Por qué no simplemente hacer esto en un solo 'pom.xml' como perfiles distintos? ¿O mejor aún, defina sus versiones de dependencia con propiedades que están establecidas en los perfiles 'dev' y' release'? – noahlz

+0

Bueno, esta fue la solución que finalmente se me ocurrió, ya que de esta forma pude definir las versiones como propiedades y usar esas propiedades en todo mi proyecto. Desafortunadamente, los chicos de Maven me están diciendo que incluso si mi compilación funciona como un hechizo, debería dejar de utilizar propiedades para versiones :-( –

Cuestiones relacionadas