tutorial run quickstart pom mvn generate example archetype maven-2

maven-2 - run - mvn archetype:generate example



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

¿Este artículo 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: fusionarse .
Tener copias interminables del número de versión en todas partes significa muchos conflictos al volver a unir ramas.

Nota:

con Maven 2.0.9 (último - abril de 2008) Simplemente he omitido el elemento de versión de los módulos individuales, ya 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.

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, tienes 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 suelta con la frecuencia que debería.

ACTUALIZACIÓN: si crees que esto es importante: ya no se tiene que especificar la versión principal. Acceda al problema de JAR de maven 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 otra pregunta de Stackoverflow que básicamente trata sobre el mismo problema.

En mi proyecto, tengo un problema así. Para reducir el número de versiones, defino en mi pom.xml principal 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, uso estas propiedades. El problema es que debo ingresar claramente la versión del padre en este pom.xml. Por ejemplo, en mi negocio pom.xml, 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 sugiero que eche un vistazo al complemento de publicación que se encargará de modificar todos los números de versión por usted.

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 hay una manera de dar una ubicación absoluta para el padre pom:

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

Si permite omitir tanto la versión del padre como la de este pom iff maven puede acceder al padre padre por la ruta relativa, ya está. La versión solo se menciona en el pom principal y en ningún otro lugar.

Me encontré con problemas similares mientras trabajaba en un gran sistema construido con Maven 2.

En mi opinión, la desventaja de la típica estructura 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óxima versión solo consiste en una corrección de foobar-jar en foobar-jar , debe cambiar la versión global en cualquier lugar (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é app1 una nueva versión de app1 y app2 , cuando se suponía que solo se debí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 (saber en qué versiones consistirá su próxima entrega, asegurarse de que las dependencias internas sean consistentes, etc.). Esto puede convertirse rápidamente en una pesadilla en una aplicación grande.

Durante mucho tiempo he pensado 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.

Aquí hay otra solución ligera hasta que se resuelva el problema del experto . 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.

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 creábamos una nueva rama teníamos que entrar en todos y cada uno de los archivos pom para cambiar el elemento <version> y también la <version> 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 principal de modo que fuera fácil eliminarlo, pero obviamente no podríamos heredar la <versión> para el <padre>.

Desafortunadamente, olvidé decirle a mi colega que era imposible, así que lo solucionó. Su solución fue agregar una propiedad al archivo padre pom:

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

Luego, en los archivos pom hijos, declaramos la etiqueta de la versión principal de esta manera:

<version>${currentVersion}</version>

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