Si utiliza Maven2 como un sistema de generación para un proyecto que contiene muchos objetos con el mismo número de versión, usted tiene la versión de la consiguiente acumulación dispersa en todos los pom.xml. En muchos de ellos, incluso dos veces – en la etiqueta de versión del artefacto en sí mismo y en la etiqueta de versión de los padres. Por lo tanto, usted tiene que cambiar y comprobar en las nuevas versiones de todos los pom.xml en cada versión del interruptor. Esto es algo molesto, especialmente si usted tiene que codificar varios corrección de errores y una versión en desarrollo en paralelo. Hay una forma de evitar eso?

ACLARACIÓN: Mi pregunta es acerca de las muchas versiones de cada uno de los pom.xml que usted consigue con el tiempo en su sistema de control de origen que sólo se diferencian por el número de versión del pom y /o el número de versión del padre pom. Idealmente, sólo es necesario cambiar el pom cada vez que agregue una dependencia o algo.

Por ejemplo, usted tiene un proyecto con los artefactos foo-pom (el padre pom para todos), foobar-jar, foobaz-jar y foo-guerra. En la primera versión de la versión 1.0 – que aparece en cada pom.xml. En la segunda versión, la versión 1.1 – que aparece de nuevo en cada pom.xml. Así que usted tiene que cambiar cada pom.xml – esto es molesto si usted liberación tan a menudo como deberían.

ACTUALIZACIÓN: Si usted cree que esto es importante: no tener que especificar la versión principal ya está siendo considerado. Por favor, vaya a la maven JIRA problema y votar por ella, la más observado y más probabilidades de ser añadido como una mejora en una próxima versión. Usted necesita para crear o tener una JIRA de inicio de sesión para que.

Hay otra Pregunta de Stackoverflow que es básicamente el mismo problema.

7 Comentarios

  1. 8

    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 típica multi-estructura del módulo es que todos los módulos
    tienen que compartir la misma versión. Esto es realmente molesto: incluso si su
    la próxima versión sólo consiste en una corrección a un error en foobar-jar, usted necesita para
    cambiar la versión global en todas partes (ya sea manualmente o con
    maven-release-plugin) y rodar una nueva versión de cada componente. En mi caso, he construido varios/GUERRA de la OREJA de aplicaciones, por lo que mi cliente me pregunta por qué me entregó una nueva versión de ambos app1 y app2, cuando sólo app1 iba a ser impactado.

    El enfoque opuesto es la gestión de cada componente como un independiente
    el proyecto, con su propia versión independiente. Esto es más flexible ya que
    permite parcial de prensa, pero ahora se necesita un seguimiento de todas estas versiones
    manualmente (saber que versiones de su próxima entrega consistirá en, hacer
    seguro dependencias internas son consistentes, etc.). Esto puede rápidamente
    convertido en una pesadilla, en una gran aplicación.

    Durante mucho tiempo he pensado en una manera de combinar los dos enfoques: la flexibilidad de versiones independientes, sin renunciar a la coherencia global del sistema. He probado el mismo enfoque que romaintaz, y se topó con el mismo problema. Finalmente, se me ocurrió esta idea:
    http://out-println.blogspot.com/2008/10/maven-modules-with-independent-versions.html.

    Considerar como «experimental», como no llegué a probarlo en vivo en la final (para los no-razones técnicas). Pero creo que haría el truco.

    • El enlace del blog está muerto, ¿puede dar un nuevo link por favor ?
  2. 7

    Sobre mi proyecto, tengo un problema. Para reducir el número de versiones que definir en casa de mis padres 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, a continuación, en el pom.xml de cada módulo, sin el uso de estas propiedades.
    El problema es que debo claramente la entrada de la versión de los padres en este pom.xml.
    Por ejemplo, en mi negocio pom.xml he:

    <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, te sugiero que eche un vistazo a la versión del plugin que se encargará de modificar todos los números de versión para usted.

    • Que es el modelo que estamos usando como bien excepto por la liberación de plugin. Me preguntaba si de alguna manera se puede evitar poner la versión original en cada pom.xml. Pero parece que usted tiene que vivir con las muchas versiones de la pom en el control de código fuente que se diferencian sólo por la versión original.
    • Creo que este enfoque puede ser complementado con Maven versión plug-in: mojo.codehaus.org/versions-maven-plugin Se puede incrementar el padre.etiqueta de versión en el niño automática de proyectos; ver versiones:actualización-niño-módulos de meta.
  3. 7

    Hace este artículo proporcionar una solución para su problema ?

    La idea es declarar el número de versión para todo el proyecto como una propiedad, a saber, la «aversión» (juego de palabras), en la matriz del pom. El padre pom propio número de versión puede ser cualquier cosa, como siempre que termina con «INSTANTÁNEA».

    Niño de los módulos de la versión se especifica a través de la ${aversión} la propiedad. Los niños de la referencia a su padre con la versión que está codificado. Sin embargo, desde que el padre pom es una versión es una INSTANTÁNEA, hijo módulos verá los cambios en la matriz del pom. En particular, si el padre pom cambia el valor de ${aversión}, los niños van a ver el cambio.

    No hay una solución perfecta, de acuerdo a los comentarios.

    Y la liberación plugin no resuelve el verdadero problema: la fusión de.

    Tener infinitas copias de la versión número en todo el lugar, significa que muchos de los conflictos cuando traigan ramas de nuevo juntos.

    Nota:

    con Maven 2.0.9 (la última de uno de abril de 2008) me han sido simplemente omitiendo la versión de los elementos de los módulos individuales como ellos heredarán la versión de su padre. Esto funciona con el groupId así si los módulos comparten el mismo groupId como su padre.

    • VonC es derecho en que se puede omitir SU pom del groupId y artifactId si quieres que sea el mismo que el de los padres. Pero el problema todavía existe, que específicamente lo que tiene que declarar la versión de su padre, incluso en un multimodule jerárquica construir.
  4. 3

    Esta es una idea para una posible extensión de maven que podría resolver el problema.
    Actualmente usted tiene que escribir la versión del artefacto y de los padres en el pom 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 la omisión de la versión de los padres y de este pom iff maven es capaz de acceder a los padres pom por la ruta de acceso relativa, está hecho. La versión sólo se menciona en los padres de pom y en ningún otro lugar.

  5. 1

    Tenemos exactamente este problema. Tenemos un gran número (alrededor de 10) de los diferentes proyectos, algunos de los cuales dependen el uno del otro. La carpeta que contiene los proyectos tiene un padre pom para el conjunto de los proyectos. Cada vez que hemos creado una nueva rama que tenía que ir a cada uno y cada una de las pom archivo para cambiar el <versión> elemento y también el <versión> para el padre, y todo esto fue la edición molesto.

    Después de leer esta pregunta y las respuestas aquí me di cuenta de que la situación era desesperada. Cada proyecto puede heredar la <versión> elemento de la matriz pom así que fue fácil de eliminar, pero es obvio que no pudo heredar el <versión> para el <padres>.

    Por desgracia, se me olvidó decirle a mi colega que era imposible, así que lo arreglen. Su solución fue agregar una propiedad a los padres pom archivo:

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

    A continuación, en el niño pom archivos hemos declarado que la versión principal de la etiqueta como esta:

    <version>${currentVersion}</version>

    No sé por qué esto funciona. No veo cómo se puede encontrar el derecho de los padres pom sin especificar el número de versión. Pero para mí (versión de maven 1.5.0_22) es se de trabajo.

    • En lugar de esto, es posible que desee considerar el uso de la versión del plugin. Esto le ayudará a cambiar los números de versión.
    • Sí, Jakrabbit, excepto por dos cosas. (1) tenemos otras peculiaridades de nuestro proceso de liberación que hacer uso de la versión plugin difícil, y (2) como he explicado, no tenemos el problema.
    • Por qué esta respuesta ha sido votada abajo? Es un godd solución (en el padre que tengo <properties><currentVersion>${version}</currentVersion></properties> para mí es trabajo
  6. 0

    Aquí es otro ligero solución hasta que el maven problema se ha resuelto. En un proyecto grande softonic no pone el pom.xml sí en el control de la versión, pero un pom-template.xml que sólo contiene un marcador de posición para el número de versión. Después de actualizar el árbol de proyecto de control de la versión que usted necesita para ejecutar una hormiguita script que genera el real pom.xml en cada directorio. Esto es molesto, pero menos molesto que tener que poner al día con todos los molestos pom versiones.

Dejar respuesta

Please enter your comment!
Please enter your name here