java - tag - mvn release perform

El complemento de lanzamiento de Maven falla: los artefactos de origen se implementan dos veces (9)

Estamos utilizando el complemento de lanzamiento maven en hudson e intentamos automatizar el proceso de lanzamiento. El lanzamiento: prepare funciona bien. Cuando tratamos de hacer la publicación: realizar, falla porque intenta subir un artefacto de origen dos veces al depósito.

Cosas que probé

eliminando el perfil que incluye el complemento de fuente maven del super pom (no funcionó)
especificando los objetivos en hudson para su publicación como -P! attach-source release: prepare release: perform. Lo cual pensé que excluiría que el complemento fuente se ejecutara. (no funcionó).
intenté especificar la fase del complemento a alguna fase no existente en el super pom. (No funcionó)
intenté especificar la configuración del complemento, forReleaseProfile como falso. (¿Adivina qué? No funcionó también)

Todavía escupe este error.

[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [INFO] [DEBUG] Checking for pre-existing User-Agent configuration. [INFO] [DEBUG] Adding User-Agent configuration. [INFO] [DEBUG] not adding permissions to wagon connection [INFO] Uploading: http://xx.xx.xx.xx:8081/nexus/content/repositories/releases//com/yyy/xxx/hhh/hhh-hhh/1.9.40/hhh-hhh-1.9.40-sources.jar [INFO] 57K uploaded (xxx-xxx-1.9.40-sources.jar) [INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [INFO] [DEBUG] Checking for pre-existing User-Agent configuration. [INFO] [DEBUG] Adding User-Agent configuration. [INFO] [DEBUG] not adding permissions to wagon connection [INFO] Uploading: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases//com/xxx/xxxx/xxx/xxx-xxx/1.9.40/xxx-xxx-1.9.40-sources.jar [INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [ERROR] BUILD ERROR [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [INFO] Error deploying artifact: Authorization failed: Access denied to: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases/com/xxx/xxx/xxx/xxx-config/1.9.40/xxx-xxx-1.9.40-sources.jar

Cualquier ayuda con respecto a esto será realmente apreciada.

Configuré el complemento de lanzamiento de maven con releaseProfile = false y no ejecuté el perfil de artefactos de origen. Que hizo el truco.

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.1</version> <configuration> <arguments>-P!source-artifacts</arguments> <useReleaseProfile>false</useReleaseProfile> <goals>-Dmaven.test.skip=true deploy</goals> </configuration> </plugin> </plugins> </build>

FWIW este problema estaba rompiendo nuestra construcción por un tiempo y la respuesta fue nada de lo de arriba. En su lugar, tontamente había establecido el aparentemente inocuo appendAssemblyId en falso en un complemento de maven-assembly para un artefacto que se adjunta (se lee desplegado, lanzado) con nuestro artefacto principal. P.ej:

<execution> <id>ci-groovy-distrib</id> <phase>package</phase> <goals> <goal>single</goal> </goals> <configuration> <descriptorRefs> <descriptorRef>my-extra-assembly</descriptorRef> </descriptorRefs>  <appendAssemblyId>false</appendAssemblyId>  <finalName>my-extra-assembly-${project.version}</finalName> </configuration> </execution>

En resumen:

el plugin de ensamblaje utiliza el id de ensamblaje como el clasificador del artefacto, por lo tanto, una parte esencial de sus coordenadas GAV únicas en términos maven (en realidad se parece más a las coordenadas GAVC - C es el clasificador).
el nombre del archivo instalado , implementado o liberado se construye a partir de estas coordenadas. No es lo mismo que el nombre de archivo que ve en su directorio de destino . Es por eso que su compilación local se ve bien, pero su lanzamiento fallará.
El elemento estúpido solo determina el nombre del artefacto de construcción local y no juega ningún papel en el resto del mismo. Es un completo engaño.

Resumen del resumen: El error 400 de Nexus se debió a que nuestro artefacto extra adjunto se estaba cargando sobre el artefacto principal, ya que tenía el mismo nombre que el artefacto principal, porque tenía las mismas coordenadas GAVC que el artefacto principal, porque Eliminé la única coordenada distintiva: el clasificador derivado automáticamente del assemblyId.

La investigación para encontrar que este era un camino largo y tortuoso, la respuesta estuvo ahí todo el tiempo en los documentos para el ensamblaje de maven:

appendAssemblyId
booleano
Establézcalo en falso para excluir el id. De ensamblado del nombre final del ensamblaje y para crear los artefactos de ensamblaje resultantes sin clasificador. Como tal, un artefacto de ensamblaje que tenga el mismo formato que el paquete del proyecto Maven actual reemplazará el archivo de este artefacto principal del proyecto .
El valor predeterminado es: verdadero.
La propiedad del usuario es: assembly.appendAssemblyId.

De http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach

El extra audaz es mío. Los documentos deberían tener una gran advertencia intermitente aquí: "Pon esto a falso y abandona toda esperanza"

Obtuve alguna ayuda de esta respuesta sobre un problema diferente maven-assembly-plugin: Cómo usar appendAssemblyId La explicación de tunaki realmente me ayudó.

He estado luchando con este tema por un tiempo y finalmente he podido resolverlo en nuestra infraestructura. Las respuestas aquí no me ayudaron, ya que no teníamos múltiples ejecuciones de los objetivos del complemento fuente y la configuración nos parecía bien.

Lo que nos perdimos fue vincular la ejecución del complemento fuente a una fase. La ampliación del ejemplo por parte de Bae, incluida la línea <fase> instalar </ fase> a la ejecución, resolvió el problema para nosotros:

<plugin> <artifactId>maven-source-plugin</artifactId> <version>2.0.4</version> <executions> <execution> <id>attach-sources</id> <phase>install</phase> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin>

Sospecho que la solución está en esta respuesta here ; diferentes complementos parecen estar invocando el objetivo jar / la ejecución attach-sources. Al vincular nuestra ejecución a una determinada fase, forzamos a nuestro complemento a ejecutarse solo en esta fase.

Intente ejecutar mvn -Prelease-profile help:effective-pom . Encontrarás que tienes dos secciones de ejecución para maven-source-plugin

La salida se verá algo como esto:

<plugin> <artifactId>maven-source-plugin</artifactId> <version>2.0.4</version> <executions> <execution> <id>attach-sources</id> <goals> <goal>jar</goal> </goals> </execution> <execution> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin>

Para solucionar este problema, busque en todas partes que haya utilizado maven-source-plugin y asegúrese de utilizar las fuentes de conexión "id" para que coincida con el perfil de publicación. Entonces estas secciones se fusionarán.

La mejor práctica dice que para obtener coherencia debe configurar esto en el POM raíz de su proyecto en build> pluginManagement y NO en sus poms secundarios. En el pom hijo, solo especifiques en los plugins build> que quieres usar maven-source-plugin, pero no proporcionas ejecuciones.

En la sala pom.xml:

<build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <executions> <execution>  <id>attach-sources</id> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> </plugins> </pluginManagement> </build>

En el pom.xml hijo:

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> </plugin> </plugins> </build>

Los complementos de Maven en poms padres e hijos no deberían tener ejecución. De acuerdo con la convención estándar, defina todos los complementos con ejecución / objetivos en el pom principal en la sección de administración de complementos. Child pom no debe redefinir los detalles anteriores, sino mencionar solo el complemento (con artifactId y versión) que debe ejecutarse.

Tuve un problema similar con maven-assembly-plugin con parent pom como a continuación:

<build> <pluginManagement> <plugins> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.6</version> <configuration> <descriptors> <descriptor>src/assembly/assembly.xml</descriptor> </descriptors> </configuration> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plugin> </plugins> </pluginManagement> </build>

Y Child pom tenía maven-assembly-plugin como a continuación:

<build> <plugins> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.2-beta-5</version> <configuration> <finalName>xyz</finalName> <descriptors> <descriptor>src/assembly/assembly.xml</descriptor> </descriptors> </configuration> <executions> <execution> <id>xyz-distribution</id> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plugin> </plugins> </build>

Eliminar el <executions> de child pom solucionó el problema. El pom efectivo tuvo 2 ejecuciones realizadas causando la duplicación de la instalación en Nepo Repo.

No creo que el probem esté en el complemento de publicación, creo que tienes el xxx-sources.jar conectado dos veces, es por eso que la carga duplicada. ¿Por qué hay un archivo adjunto duplicado es difícil de ver sin ver el POM. Intenta ejecutar mvn -X y mvn -X el registro para ver quién conecta xxx-source.jar otro momento.

En cualquier caso, una buena solución en Nexus sería tener un repositorio de etapas donde pueda cargar comunicados varias veces, y cuando todo esté listo, simplemente cierre / promocione el repositorio de etapas. Compruebe la configuración de Sonatype OSS para ver un ejemplo.

Sé que esta pregunta es antigua, pero Google hit # 1 hoy así que agregaré mi respuesta apropiada para las versiones recientes de maven 3.

El síntoma es que las fuentes y javadoc jar se implementan dos veces cuando se realiza una versión de lanzamiento con algunas versiones de maven 3. Si está utilizando maven para implementar sus artefactos en un repositorio Sonatype Nexus que solo permite cargar un artefacto de liberación una vez (que es un comportamiento totalmente razonable), la construcción falla cuando se rechaza el segundo intento de carga. Argh!

Las versiones 3.2.3 a 3.3.9 de Maven tienen errores: consulte https://issues.apache.org/jira/browse/MNG-5868 y https://issues.apache.org/jira/browse/MNG-5939 . Esas versiones generan y despliegan fuentes y javadoc jar dos veces al hacer una versión.

Si leo el rastreador de problemas de Maven correctamente, esos errores no están programados para correcciones al momento de escribir esto (la versión grabada de 3.4.0 probablemente los afectó).

En lugar de un ajuste complejo a mi pom, mi solución simple fue recurrir a la versión 3.2.1 de Maven.

Simplemente habiendo golpeado el mismo problema, lo analicé un poco. mvn release:perform evalúa el archivo release.properties, luego verifica la etiqueta en un directorio temporal e invoca allí algo así como

/usr/bin/mvn -D maven.repo.local=... -s /tmp/release-settings5747060794.xml -D performRelease=true -P set-envs,maven,set-envs deploy

Traté de reproducir esto, compruebe manualmente la etiqueta producida por la release:prepare e invoque esto:

mvn -D performRelease=true -P set-envs,maven,set-envs deploy

Obtuve el mismo resultado: intentaba subir -sources.jar dos veces.

Como se señala por qualidafial en un comentario, la configuración de performRelease=false omite uno de los dos archivos adjuntos del mismo archivo.

Realmente no tengo una idea de cómo el plugin deploy (o cualquier otro plugin) usa esta propiedad.

Podemos proporcionar este parámetro como una configuración para maven-relase-plugin:

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.3.2</version> <configuration> <useReleaseProfile>false</useReleaseProfile> </configuration> </plugin> </plugins> </build>

Ahora agregué la línea <useReleaseProfile>false</useReleaseProfile> a todos los POM, y parece que liberar ahora funciona sin un mensaje de error.

Yo tuve el mismo problema. Básicamente, el mensaje de error se emite cuando se envía un artefacto a Nexus dos veces. Esto puede ser dos veces al mismo repositorio Nexus o incluso a través de diferentes repositorios dentro del mismo Nexus.

Sin embargo, las razones de una mala configuración pueden variar. En mi caso, los artefactos se cargaron correctamente durante un paso de despliegue de implementación de mvn clean en Jenkins, pero luego fallaron cuando se intentó un segundo despliegue. Este segundo despliegue se configuró en un paso de compilación posterior de Jenkins "Publicación de artefactos en el repositorio de Maven".