consejos Maven en relación con el control de versiones de un gran proyecto y la evitación de las versiones que contienen expresiones

Question

estoy mirando a la reestructuración de un gran proyecto de Maven ...

Una descripción básica de nuestra estructura actual:

build [MVN plugins, third party dependency management]:5.1 
    NRW Utils:6.0.0.0-beta12-SNAPSHOT 
     server-utils:6.0.0.0-beta12-SNAPSHOT 
     ... 
    CMW Root:6.0.0.0-beta12-SNAPSHOT 
     cmw-webapp:6.0.0.0-beta12-SNAPSHOT 
     cmw-core [dependencies on NRW Utils]:6.0.0.0-beta12-SNAPSHOT 
     ... 
    NRW Root :6.0.0.0-beta12-SNAPSHOT 
     nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-beta12-SNAPSHOT 
     ... 

la razón para el cambio:

el tamaño de cada módulo colectivo (es decir, NRW Utilidades, CMW Root y NRW Root) es grande y la buil d El proceso comienza a tomar una cantidad de tiempo insoportable (~ 4 horas a veces).

El nuevo plan:

build [MVN plugins, third party dependency management]:5.1 
    NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT 
     server-utils:6.0.0.0-NU-beta4-SNAPSHOT 
     ... 
    CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT 
     ... 
    NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT 
     nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT 
     ... 

Hemos empezado a introducir 'llaves' en la versión para distinguir entre diferentes módulos 'colectivos' y por lo tanto se pueden realizar fácilmente las liberaciones escalonadas. Además, nuestros módulos de utilidad son mucho más estables, por lo que es posible que no necesitemos casi tantas versiones beta: ahora no hay restricciones para mantener sincronizados los números beta.

También vale la pena señalar que de hecho hay 5 diferentes 'módulos colectivos' (no solo 3) todos para ser construidos con diferentes versiones (distinguidas por claves únicas) por lo que pensé que sería bueno tener un lugar centralizado para las versiones, en oposición a las propiedades duplicadas en 5 diferentes POM.

El problema ahora radica en los contenidos de los archivos POM cuando se definen las dependencias de módulos en un 'módulo colectivo' diferente de una versión diferente.

La solución propuesta a la dependencia de gestión de versiones:

build [MVN plugins, third party dependency management]:5.1 
    nrw-version-management:6.0.0.0-beta-SNAPSHOT 
     [contains properties defining latest versions of each collective module] 
     NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT 
     server-utils:6.0.0.0-NU-beta4-SNAPSHOT 
     ... 
     CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT 
     ... 
     NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT 
     nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT 
     ... 

NRW-versión-gestión (pom.xml):

... 
<parent> 
    <groupId>com.project</groupId> 
    <artifactId>build</artifactId> 
    <version>5.1</version> 
</parent> 
<groupId>com.project</groupId> 
<artifactId>nrw-versions-manager</artifactId> 
<version>6.0.0.0-beta-SNAPSHOT</version> 
<name>Version Maven Properties</name> 
<description>A centralised place for all module property versions</description> 
<packaging>pom</packaging> 
<properties> 
    <nrw.utilities.version>6.0.0.0-NU-beta4-SNAPSHOT</nrw.utilities.version> 
    <nrw.cmw.version>6.0.0.0-CMW-beta12-SNAPSHOT</nrw.cmw.version> 
    <nrw.version>6.0.0.0-NRW-beta9-SNAPSHOT</nrw.version> 
</properties> 
... 

CMW Root (pom.xml):

... 
<parent> 
    <groupId>com.project</groupId> 
    <artifactId>nrw-versions-manager</artifactId> 
    <version>${nrw.core.version}</version> 
    ... 
</parent> 
<groupId>com.project</groupId> 
<artifactId>CMW-root</artifactId> 
<version>6.0.0.0-CMW-beta12-SNAPSHOT</version> 
<packaging>pom</packaging> 
<dependencyManagement> 
    <dependencies> 
     ... 
     <dependency> 
      <groupId>${project.groupId}</groupId> 
      <artifactId>server-utils</artifactId> 
      <version>${nrw.utilities.version}</version> 
     </dependency> 
     ... 
</dependencyManagement> 
<profiles> 
    <profile> 
     <id>all</id> 
     <modules> 
      <module>cmw-webapp</module> 
      <module>cmw-core</module> 
      ... 
     </modules> 
    </profile> 
    ... 
</profiles> 
... 

N.B. la propiedad $ {nrw.core.version} se establecería en 6.3.0.0-beta-SNAPSHOT para una compilación de instantánea a través de argumentos de línea de comando (o un valor de propiedad predeterminado).

Un posible proceso de liberación (por 6.0.0.0):

1. construir el módulo 5.1 build si no está ya construida
2. Construir NRW-versión-gestión 6.0.0.0 (para evitar dependencias de instantáneas - Sin embargo no hay propiedades se cambian aún)
3. Build NRW Utilidades 6.0.0.0-NU args cmd: -Dnrw.core.version = 6.0.0.0
4. Construir CMW Root 6.0.0.0-CMW args cmd: -Dnrw. core.versi on = 6.0.0.0 -Dnrw.utilities.version = 6.0.0.0-NU
5. Build NRW Root 6.0.0.0-NRW cmd args: -Dnrw.core.version = 6.0.0.0 -Dnrw.utilities.version = 6.0 .0.0-NU -Dnrw.cmw.version = 6.0.0.0-CMW
6. Reformado NRW-versión-gestión 6.0.0.0 para el repositorio de args cmd: -Dnrw.core.version = 6.0.0.0 -Dnrw.utilities.version = 6.0.0.0-NU -Dnrw.cmw. versión = 6.0.0.0-CMW
-NRW-gestión de versiones
7. Build 6.1.0.0-beta-INSTANTÁNEA con nuevas versiones dev y archivo de actualización POM

El problema:

El proceso de construcción parece prolijo, especialmente relacionado con el módulo nrw-version-management. Además, empecé a ver esta advertencia:

'versión' contiene una expresión, pero debe ser una constante

y habiendo hecho algunas investigaciones ahora entiendo no se recomiendan las expresiones al configurar versiones (cuando se especifica un POM padre):

• Warning on using project.parent.version as the version of a module in Maven 3
• Maven: property substitution not done for /project/version tag of pom?
• http://maven.40175.n5.nabble.com/Pom-Parent-Version-Properties-td124576.html

Las preguntas:

• ¿Puedo simplemente ignorar esta advertencia? Algunas publicaciones están comenzando a sugerir que podría ser aceptable especificar versiones principales de POM usando propiedades.
• ¿Este enfoque general es convencional? ¿O defectuoso?
• ¿Existen mejores soluciones para abordar la reestructuración de este proyecto en crecimiento?

Gracias de antemano.

Answer 1

No creo que apegarse a una sola versión en todo el proyecto sea viable en esta etapa, dado que el proceso de construcción lleva tanto tiempo ahora (el otro día falló después de 7 horas !!).

Sin embargo, los dos enlaces inferiores no responden completamente a mi pregunta, pero son cada vez existe:

• How to share common properties among several maven projects?
• How do I tell Maven to use the latest version of a dependency?

Answer 2

Las ventajas de tener una única versión para todos los módulos secundarios es la simplicidad, un beneficio que no debe subestimarse.

Debería preguntarse varias veces si realmente desea depender de diferentes versiones de módulos en la misma jerarquía. Como usted señaló, la liberación se vuelve engorrosa.

Al manejar las relaciones de forma estandarizada con una única versión y desplegarlas en su repositorio local después de compilaciones exitosas, debería poder disfrutar de la administración de dependencias de la manera en que se pretendía.

Si reestructura su proyecto para que se adhiera a las convenciones del complemento de publicación, la liberación se convierte en una brisa.

Answer 3

Como nico_ekito se indica en uno de los comentarios, en mi propia opinión, usted está cayendo ahora en la "pesadilla de la gestión de la dependencia". Según su escenario ... ¿no es el hecho de administrar versiones diferentes para los submódulos (así como la estabilidad de un código diferente) un síntoma de que esos submódulos ya no son parte del gran proyecto?

Quiero decir, nosotros, como seres humanos, podemos afirmar claramente que esos módulos son parte del panorama general, todo el enfoque para resolver un problema. Eso es bastante común cuando descubre que sus clases de utilidad no tienen uso fuera del alcance de esa gran imagen. Pero, desde el punto de vista de Maven, creo que en realidad se trata de proyectos diferentes en lugar de módulos de uno grande.

Por lo tanto, tal vez vale la pena separar las bases de código en diferentes estructuras y simplemente hacer referencia a los archivos de utilidad de los módulos que realmente lo requieren y simplemente usar compilaciones estables en lugar de "última versión de esa dependencia". Si se trabaja con compilaciones estables, no es factible porque, a pesar de que el código para esas dependencias es bastante estable, sigue cambiando al mismo tiempo que el código de los otros módulos, entonces la solución que Maven le da es usar SNAPSHOTS.

creo que usted encontrará algunos beneficios al romper el código base en proyectos separados:

• De esa manera Maven no activará una acumulación en los módulos de utilidad cuando no es necesario.
• Si puede encontrar la manera de simplemente usar versiones estables para las dependencias, evitará muchas molestias.
• También puede dividir el equipo y hacer que funcionen solo con los archivos jar de utilidad hacerlo "por debajo de la demanda" del equipo que consume esas dependencias.
• Si esas utilidades son abstractas o reutilizables, es posible que algún día otro proyecto las consuma sin la necesidad de hacer referencia a un submódulo de un proyecto más grande.

Hay mucha discusión en Internet sobre la forma Maven handles dependencies (y otras cosas) y una gran cantidad de personas que se quejan de los mismos problemas que está enfrentando. En mi opinión, Maven es una gran herramienta, diseñada para ahorrarnos mucho tiempo al iniciar nuevos proyectos, pero a veces puede ser un poco engorroso. Empecé a echar un vistazo a otras herramientas como Gradle, pero ahora cambiar la herramienta de compilación puede ser peor. Simplemente dando un pensamiento a la idea de romper la base del código, a veces podemos resolver un "problema de software" simplemente con un poco de "gestión de proyectos" (o "gestión de cartera" en este caso).