Jerarquía de proyectos maven sin dispersar el número de versión

Question

Si usa Maven2 como un sistema de compilación para un proyecto que contiene muchos artefactos con el mismo número de versión, tiene la versión de la compilación resultante dispersa en todo pom.xml. En muchos de ellos, incluso dos veces, en la etiqueta de versión del artefacto en sí y en la etiqueta de versión del padre. Por lo tanto, debe cambiar y verificar las nuevas versiones de todos los pom.xml en cada cambio de versión. Esto es algo molesto, especialmente si tiene que codificar varias correcciones de errores y una versión de desarrollo en paralelo. ¿Hay alguna manera de evitar eso?

ACLARACIÓN: Mi pregunta es acerca de las muchas versiones de cada pom.xml que obtiene con el tiempo en su sistema de control de origen que difieren únicamente por el número de versión del pom y/o el número de versión del pom padre. Idealmente, solo debería cambiar el pom cada vez que agregue una dependencia o algo.

Por ejemplo, tiene un proyecto con los artefactos foo-pom (el padre pom para todos), foobar-jar, foobaz-jar y foo-war. En el primer lanzamiento, la versión es 1.0, que aparece en cada pom.xml. En el segundo lanzamiento, la versión es 1.1, que aparece de nuevo en cada pom.xml. Por lo tanto, debe cambiar cada pom.xml; esto es molesto si lo libera con la frecuencia que debería.

ACTUALIZACIÓN: Si crees que esto es importante: ya no se tiene que especificar la versión principal. Vaya al maven JIRA issue y vote para que sea más notorio y más probable que se agregue como una mejora en un próximo lanzamiento. Necesita crear/tener un inicio de sesión JIRA para eso.

Hay another Stackoverflow Question que es básicamente el mismo problema.

Answer 1

Hay another StackOverflow thread that also covers this topic that you might want to look at.

En resumen, no tener que especificar la versión principal cuando se usa la herencia es already being considered. Please go over to JIRA and give it a vote bump para que sea más notorio y más probable que se agregue como una mejora en una próxima versión.

Answer 2

En mi proyecto, tengo un problema. Para reducir el número de versiones defino en mi padre pom.xml algunas propiedades, que corresponden a las versiones de cada módulo:

<properties> 
    <project-version>1.0.0</project-version> 
    <!-- Same version than the parent for the module 'commons' --> 
    <project-commons-version>${project-version}</project-commons-version> 
    <!-- A specific version for the 'business' module --> 
    <project-business-version>1.0.1</project-business-version> 
    ... 

Y luego, en el pom.xml de cada módulo, utilizo estas propiedades. El problema es que debo ingresar claramente la versión del padre en este pom.xml. Por ejemplo, en mi pom.xml negocio, que tengo:

<project> 
    <modelVersion>4.0.0</modelVersion> 
    <!-- I must indicate the version of the parent --> 
    <parent> 
    <groupId>my.project</groupId> 
    <artifactId>parent</artifactId> 
    <version>1.0.0</version> 
    </parent> 
    ... 
    <dependencies> 
    <!-- However, in my dependencies, I use directly the properties defined in the parent's pom.xml --> 
    <dependency> 
     <groupId>my.project</groupId> 
     <artifactId>project-persistence</artifactId> 
     <version>${project-persistence-version}</version> 
    </dependency> 

Sin embargo, realmente sugieren que echar un vistazo a la release plugin que se encargará de modificar todos los números de versión para usted.

Answer 3

¿Esto article proporciona una solución para su problema?

La idea es declarar el número de versión para todo el proyecto como una propiedad, es decir, "aversión" (juego de palabras intencionado), en el pom padre. El número de versión del padre pom puede ser cualquier cosa, siempre que termine con "SNAPSHOT".

La versión de los módulos secundarios se especifica mediante la propiedad $ {aversion}. La referencia de los niños a la versión de sus padres está codificada. Sin embargo, dado que la versión del padre pom es SNAPSHOT, los módulos secundarios verán los cambios en el pom padre. En particular, si el padre pom cambia el valor de $ {aversion}, los hijos verán el cambio.

No es una solución perfecta según los comentarios.

Y el complemento de lanzamiento no resuelve el problema real: fusionando.
Tener un número interminable de copias del número de versión significa muchos conflictos al volver a unir ramas.

Nota:

con Maven 2.0.9 (más reciente - abril de 2008) que han sido simplemente omitiendo el elemento de la versión de los módulos individuales a medida que heredarán la versión de sus padres. Esto también funciona con groupId si sus módulos comparten el mismo ID de grupo que su padre.

Answer 4

Esta es una idea para una posible extensión de maven que resolvería el problema. Actualmente tiene que escribir la versión a del artefacto y del pom padre en el pom.xml. Ya existe una manera de dar una ubicación absoluta para el pom padres:

<parent> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>my-parent</artifactId> 
    <version>2.0</version> 
    <relativePath>../my-parent</relativePath> 
</parent> 

Si permite omitiendo tanto de la versión de los padres y de esta experta pom si y sólo si es capaz de acceder al pom de los padres por la ruta relativa , estás listo. La versión solo se menciona en el pom principal y en ningún otro lugar.

Answer 5

me he encontrado con problemas similares mientras se trabaja en un sistema grande construido con Maven 2.

En mi opinión, la desventaja de la estructura típica de varios módulos es que todos los módulos tienen que compartir la misma versión . Esto es ciertamente molesto: incluso si su próximo lanzamiento solo consiste en una corrección de error en foobar-jar, necesita cambiar la versión global en todas partes (ya sea manualmente o con maven-release-plugin) y lanzar una nueva versión de cada componente. En mi caso, construí varias aplicaciones WAR/EAR, por lo que mi cliente me preguntaba por qué entregué una nueva versión de app1 y app2, cuando se suponía que solo se afectaría app1.

El enfoque opuesto es administrar cada componente como un proyecto independiente , con su propia versión independiente. Esto es más flexible ya que permite versiones parciales, pero ahora necesita realizar un seguimiento de todas estas versiones manualmente (sepa en qué versiones consistirá su próxima entrega, haga para asegurarse de que las dependencias internas sean consistentes, etc.). Esto puede rápidamente convertirse en una pesadilla en una aplicación grande.

Hace tiempo que pensé en una forma de combinar ambos enfoques: la flexibilidad de las versiones independientes, sin renunciar a la coherencia global del sistema. Probé el mismo enfoque que romaintaz, y encontré el mismo problema. Finalmente, se me ocurrió esta idea: http://out-println.blogspot.com/2008/10/maven-modules-with-independent-versions.html.

Considérelo como 'experimental', ya que al final no pude probarlo en vivo (por razones no técnicas). Pero creo que haría el truco.

Answer 6

Aquí hay otra solución ligera hasta que se resuelva el maven issue. En un proyecto grande, ya no ponemos el propio pom.xml en el control de versiones, sino un pom-template.xml que solo contiene un marcador de posición para el número de versión.Después de actualizar el árbol del proyecto desde el control de la versión, debe ejecutar un pequeño script ant que genere el pom.xml real en cada directorio. Esto es molesto, pero menos molesto que tener que aguantar todas esas molestas versiones de pom.

Answer 7

Tenemos exactamente este problema. Tenemos un gran número (alrededor de 10) de diferentes proyectos, algunos de los cuales dependen el uno del otro. La carpeta que contiene los proyectos tiene un pom padre para todo el conjunto de proyectos. Cada vez que creamos una nueva rama teníamos que ir a todos y cada uno de los archivos pom para cambiar el elemento < versión> y también la versión <> para el padre, y toda esta edición era molesta.

Después de leer esta pregunta y las respuestas aquí me di cuenta de que la situación era inútil. Cada proyecto podría heredar el elemento < version> del padre padre de modo que fuera fácil de eliminar, pero obviamente no podríamos heredar la versión <> para el padre <>.

Desafortunadamente, olvidé decirle a mi colega que era imposible, por lo que lo arregló. Su solución fue añadir un alojamiento a la matriz archivo POM:

<properties><currentVersion>2.6.1-SNAPSHOT</currentVersion></properties> 

Luego, en los archivos del pom niño que declaramos la etiqueta de versión para padres así:

<version>${currentVersion}</version> 

No sé por qué esto funciona . No veo cómo puede encontrar el pom padre correcto sin especificar el número de versión. Pero para mí (maven versión 1.5.0_22) es está trabajando.