¿Cómo se puede usar maven en una situación de integración continua para instalar artefactos versionados en el repositorio?

Question

Estamos en el proceso de convertir nuestro proceso de construcción principal de hormiga a maven. Usamos TeamCity para nuestro servidor de Integración Continua (CI).

Nos gustaría utilizar el servidor de CI para dar inicio a las compilaciones (cada noche) cuya versión contiene un número de compilación, como en 1.0.0.build #. Estas compilaciones se instalarían en nuestro repositorio maven local para ser utilizadas por otros proyectos. Entonces, el servidor de CI administraría las versiones, maven construiría el proyecto y el repositorio maven haría las compilaciones accesibles para otros proyectos.

tenía la intención de iniciar la construcción del servidor de CI con el siguiente comando:

mvn -Dversion=1.0.0.25 install 

pom del proyecto podría tener un número de versión falsa, y la bandera -D sería anularlo, como en:

<version>0.0.0.0</version> 

El problema con este método es que el complemento de instalación maven solo usa la versión en el archivo pom, no la versión que se pasa en la línea de comandos. Esto se observa en this maven issue.

Así que como este problema existe desde 08/2006 y no se ha solucionado, supongo que de alguna manera no es 'el modo'. Entonces mi pregunta es, ¿cómo se puede usar maven en una situación de integración continua para instalar artefactos versionados en el repositorio?

Answer 1

Parece que desea compilar versiones de SNAPSHOT con versiones únicas.

Así, en su POM declarar la versión que:

<version>#.#.#-SNAPSHOT</version> 

Luego, en el sección distributionManagement del POM, permiten versiones únicas para el snapshotRepository vía (ver Maven de POM reference en esto):

<snapshotRepository> 
    <uniqueVersion>true</uniqueVersion> 
    <id>your-snapshot-repo-id</id> 
    <name>Your Snapshots</name> 
    <url>http://your-snapshot-repo-url/maven</url> 
</snapshotRepository> 

FYI, tenga en cuenta que las versiones Maven conventions recomiendan ser declarados como major.minor.revision. Entonces, 1.0.25 en lugar de 1.0.0.25. Si puedes usar este esquema de control de versiones, todo funcionará mejor en un mundo Maven.

Answer 2

La respuesta de Shek es probablemente "la mejor manera", así que la aceptaré como la respuesta correcta. Sin embargo, no estamos listos para cambiar nuestras convenciones, así que aquí está la solución que estamos usando.

Al usar un nivel de direccionamiento indirecto, puede pasar un número de versión al pom en tiempo de compilación y hacer que los complementos de instalación y despliegue los usen. Por ejemplo:

<project xmlns="..." xmlns:xsi="..." xsi:schemaLocation="..."> 
    <modelVersion>4.0.0</modelVersion> 
    <groupId>com.stackoverflow</groupId> 
    <artifactId>stackoverflow</artifactId> 
    <version>${ciVersion}</version> 
    <packaging>jar</packaging> 
    <name>StackOverflow</name> 

    <properties> 
    <ciVersion>0.0.0.0</ciVersion> 
    </properties> 

    ... 

</project> 

No podemos anular $ {project.version} directamente. Entonces, en su lugar, agregamos una segunda propiedad llamada 'ciVersion' y le damos un valor predeterminado de '0.0.0.0' en la sección de propiedades. Ahora el servidor de CI puede especificar un número de versión anulando la propiedad ciVersion en la línea de comando. Como en:

mvn -DciVersion=1.0.0.25 install 

El instalar y desplegar plugins utilizará el valor de la propiedad ciVersion que fue aprobada en cada vez que se hace referencia $ {} project.version, como se esperaba, y se usará el valor por defecto cuando no hay ninguna versión se proporciona en la línea de comando.Esto nos permite cambiar a maven con un impacto mínimo en nuestro proceso. Además, esta solución no es molesta, lo que permite un cambio fácil a la funcionalidad SNAPSHOT cuando lo desee.

Answer 3

Matthew's answer proporciona una solución donde los artefactos se cargan en el repositorio local y remoto que tiene el número de versión deseado, es decir, las rutas dentro del repositorio contienen los números de versión correctos; sin embargo, Maven instala e implementa siempre el archivo POM fuente que aún contendría el ${ciVersion} en el elemento de versión.

Si usted tiene un multi-módulo con un padre común como esto:

<project xmlns="..." xmlns:xsi="..." xsi:schemaLocation="..."> 
    <modelVersion>4.0.0</modelVersion> 
    <parent> 
    <artifactId>myParent</artifactId> 
    <groupId>com.stackoverflow</groupId> 
    <version>${ciVersion}</version> 
    </parent> 
    <artifactId>myChild</artifactId> 
    ... 
</project> 

usted no será capaz de hacer referencia a una versión dedicada del módulo myChild, ya que existirá la resolución de dependencias con un error que no puede encontrar el módulo myParent con la versión ${ciVersion}.

Sin embargo, puede usar el resolve-pom-maven-plugin que carga un POM en el repositorio local y remoto donde todas las variables dentro del POM se sustituyen por sus valores reales. Para hacer esto, debe agregar el siguiente fragmento en su POM (principal):

... 
<build> 
    <plugins> 
    <plugin> 
     <groupId>com.sap.prd.mobile.ios.maven.plugins</groupId> 
     <artifactId>resolve-pom-maven-plugin</artifactId> 
     <version>1.0</version> 
     <executions> 
     <execution> 
      <id>resolve-pom-props</id> 
      <goals> 
      <goal>resolve-pom-props</goal> 
      </goals> 
     </execution> 
     </executions> 
    </plugin> 
    </plugins> 
</build> 
...