Versiones del proyecto Maven 2, versiones de dependencia y publicación perpetua

Escenario: el sistema tiene una cantidad de componentes, cada uno con su propio POM. Hay algunas cadenas de dependencia largas (A depende de B depende de C, etc.). Quiero que cada compilation de "escritor que no sea de desarrollador" sea un posible candidato de lanzamiento; si pasa el control de calidad, lo implementaremos sin reconstrucción. En otras palabras, no quiero build versiones de SNAPSHOT como parte de mis comstackciones progtwigdas regularmente, solo versiones como 1.3.0.5, 1.3.0.6, etc. También quiero permitir que los desarrolladores trabajen en múltiples componentes a la vez.

Para anticipar algunas sugerencias esperadas: el complemento Maven Release no me ayuda … a less que haya alguna forma mágica de que mis versiones de dependencia no sean SNAPSHOT en los POM pero aún así permitan que los desarrolladores trabajen en más de un componente a la vez.

¿Cómo debemos gestionar el proyecto y las versiones de dependencia en todos nuestros POM? En este momento solo se trata de SNAPSHOT en todas partes, lo que simplifica las cosas para los desarrolladores (comenzaron con SNAPSHOT y nunca se preocuparon por nada más). Pero es preocupante en el momento del deployment (las comstackciones con dependencies SNAPSHOT no están bien definidas y no son reproducibles).

Me gustaría evitar el malabarismo excesivo en time de compilation, pero en este momento no veo ninguna forma de evitarlo.

Digamos que tengo los componentes util, libj, libk, APP y UI, con dependencies de la siguiente manera:
libj -> util (libj depende de la utilidad)
libk -> util
APLICACIÓN -> libj
UI -> libj, libk

Tengo equipos de desarrollo trabajando en APP y UI, y en ocasiones necesitarán hacer cambios / adiciones a algunas de las dependencies (incluso utilidades) para habilitar su trabajo actual. ¿Cómo deberían verse las versiones de POM y de dependencia registradas para cada componente?

Editar: actualicé el título para referirme a Maven 2 en lugar de 2.0, ya que resultó evidente que tendría que trabajar con 2.1 o mejor para poder resolverlo mejor.

Intente diseñar sus comstackciones de modo que los modules que necesitan desarrollarse juntos se liberen juntos. Esto permitirá que el complemento de lanzamiento maven haga la mayor parte del trabajo por usted.

Para las dependencies que realmente deberían tener un ciclo de vida separado … porque cambian con poca frecuencia o son compartidas por varios proyectos, usted desea manejarlas de manera diferente. La forma en que lo hago es mantener las dependencies en la última versión de lanzamiento hasta que un cambio realmente requiera una actualización a la siguiente instantánea. De esta forma, cuando vaya a lanzar el producto, encontrará todas las cosas que también pueden lanzarse simplemente siguiendo los pasos de la instantánea.

También me parece útil mantener las versiones de dependencies externas especificadas como properties en la parte superior de mi proyecto. Esto hace que sea fácil ver de un vistazo lo que debe ser liberado. Busque un ejemplo de Nexus pom.

Esto es algo que encuentro muy difícil con maven y proyectos internos; tienes dos sistemas de control de versiones (los de Maven, que francamente no son muy buenos) y los controles de tu código fuente (que, suponiendo que sea CVS o mejor, admite un flujo de trabajo real).

Así es como lo hacemos:

report --depends on--> core web --depends on--> core 

Usamos el enchufe de liberación Maven:

pom del informe, durante el desarrollo, tendría una versión de SNAPSHOT que coincida con lo que está en el pom del núcleo. Hago una mvn clean install en core, luego puedo ver esos cambios en el report en mi entorno local.

Cuando publique un informe, primero debo liberar el núcleo a través del conector de lanzamiento de Maven. Cuando lo uso en core, me pide que configure la versión de core para liberarla (es decir, elimino -SNAPSHOT), a lo que respondo que sí, y el artefacto liberado resultante no depende de una versión de SNAPSHOT. Cuando se completa el complemento de publicación, el informe ahora depende de la próxima versión de SNAPSHOT del núcleo (aunque puede anularlo durante la mvn release:prepare si lo desea).

Luego, los desarrolladores en la web reciben un correo electrónico con una nueva versión del núcleo disponible y pueden elegir usarlo si lo desean. Nuestra política es que se actualicen antes de la publicación.

Este es realmente el mismo problema que alguien necesitando un código de bifurcación en el que están trabajando. Necesita algún tipo de identificador para poder acceder a la versión específica hasta que se vuelva a fusionar con el desarrollo principal de ese componente.

El clasificador de dependencia puede ser algo que valga la pena investigar. Aún necesitará tener desarrolladores que identificarán correctamente su código modificado.

trabajamos con un proyecto .pom "Super Parent", en él las versiones se definen como properties y en cada proyecto. child, las versiones se establecen con esas properties

Además, los proyectos reales no tienen un set de versiones, sino que lo henetworkingan de su pom-project principal (incluido groupId, etc.)

con esta configuration, las versiones solo se definen en algunos pom-projects principales, por lo que se minimiza la configuration necesaria

por ejemplo, esta estructura

  • super parent pom-project (todas las versiones de terceros como properties definidas, p. ej., 2.5.6 spring-framework) —- persistence-parent pom-project, henetworkinga todas de super parent —— persistence-foobar jar project, henetworkinga todo de persistence-parent —- util-parent

etc.

solo las versiones que ve son las que están dentro del ejemplo de relaciones padre:

  <modelVersion>4.0.0</modelVersion> <artifactId>foo-bar-foo</artifactId> <packaging>jar</packaging> <name>whatever</name> <description>...</description> <parent> <groupId>org.foo.bar</groupId> <artifactId>persistence-parent</artifactId> <version>1.0-SNAPSHOT</version> </parent> <dependencies> <dependency> <groupId>${project.groupId}</groupId> <artifactId>foo-bar</artifactId> <version>${project.version}</version> </dependency> <dependency> <groupId>${project.groupId}</groupId> <artifactId>foo-bar</artifactId> <version>${project.version}</version> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>org.springframework.jdbc</artifactId> <version>${parent.spring.version}</version> </dependency> 

funciona de esta manera, porque dentro de la pom puede usar valores ya definidos como la versión, incluso si la versión se establece a través de la inheritance

combinamos esto con configuraciones de modules dentro de los proyectos principales para facilitar las construcciones