Maven release plugin falla: los artefactos de origen se implementan dos veces

Sé que esta pregunta es antigua, pero fue 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 los jars de javadoc se despliegan dos veces cuando se hace una compilació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 que un artefacto de liberación se cargue una vez (lo que es un comportamiento totalmente razonable), la compilación falla cuando se rechaza el segundo intento de carga. Argh!

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

Si leo correctamente el Maven issue tracker, esos errores no están programados para ser corregidos en el momento de escribir este artículo (la versión 3.4.0 quemada probablemente los afectó).

En lugar de un ajuste complejo a mi pom, mi simple la solución era 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 la liberación.archivo de propiedades, luego comprueba la etiqueta en un directorio temporal e invoca allí algo como

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

Intenté reproducir esto-manualmente comprobé la etiqueta producida por release:prepare e invoqué esto:

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

Obtuve el mismo resultado: Estaba tratando de cargar las fuentes.jar dos veces.

Como señaló qualidafial en un comentario, el ajuste performRelease=false omite uno de los dos adjuntos del mismo archivo.

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

Podemos proporcionar este parámetro como una configuración del 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 POMs, y parece que la liberación ahora funciona sin un mensaje de error.

He estado luchando con este problema durante un tiempo y finalmente he sido capaz de resolverlo en nuestra infraestructura. Las respuestas aquí no me ayudaron, ya que no teníamos varias ejecuciones de los objetivos del complemento de origen y la configuración nos pareció bien.

Lo que nos perdimos fue vincular la ejecución del complemento de origen a una fase. Extender el ejemplo por Bae, incluyendo la línea install 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 aquí ; diferentes plugins parecen estar invocando el objetivo jar / la ejecución de attach-sources. Al vincular nuestra ejecución a una determinada fase, forzamos nuestro plugin solo para ser ejecutado en esta fase.

No creo que el probem está en el plugin de lanzamiento, creo que tienes el xxx-sources.jar adjunto dos veces - es por eso que la carga duplicada. ¿Por qué hay un archivo adjunto duplicado es difícil de decir sin ver el POM. Intente ejecutar mvn -X y comprobar el registro para saber quién adjunta xxx-source.jar en otra ocasión.

En cualquier caso, una buena solución en Nexus sería tener un repositorio de staging donde se pueden cargar versiones varias veces, y cuando todo esté listo, simplemente cerrar/promover el repositorio de staging. Compruebe el Sonatype OSS setup para ver un ejemplo.

Yo tenía 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 tal mala configuración pueden variar. En mi caso, los artefactos se cargaron correctamente durante un paso de compilación de mvn clean deploy en Jenkins, pero luego fallaron cuando se intentó una segunda implementación. Este segundo deploy se había configurado en un Jenkins paso "Publicar artefactos en el repositorio Maven".

Los plugins Maven en poms padre e hijo no deberían tener ejecución. Según la convención estándar, defina todos los complementos con ejecución / objetivos en pom padre en la sección de administración de complementos. Child pom no debe redefinir los detalles anteriores, sino mencionar solo el plugin (con artifactId, y versión) que necesita ser ejecutado.

Tuve un problema similar con maven-assembly-plugin con pom padre 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 pom Hijo 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>

Eliminando el <executions> de niño pom rectificado el problema. El pom efectivo tenía 2 ejecuciones realizadas causando la instalación duplicada al repositorio Nexus.

FWIW este problema estaba rompiendo nuestra compilación por un tiempo y la respuesta era ninguna de las anteriores. En su lugar, había establecido tontamente el aparentemente inocuo appendAssemblyId a false en un maven-assembly-plugin para un artefacto que se adjunta (leer desplegado, liberado) con nuestro artefacto principal. Por ejemplo:

    <execution>
        <id>ci-groovy-distrib</id>
        <phase>package</phase>
        <goals>
            <goal>single</goal>
        </goals>
        <configuration>
            <descriptorRefs>
                <descriptorRef>my-extra-assembly</descriptorRef>
            </descriptorRefs>

            <!-- This is the BUG: the assemblyID MUST be appended 
                 because it is the classifier that distinguishes 
                 this attached artifact from the main one!
            -->
            <appendAssemblyId>false</appendAssemblyId>
            <!-- NOTE: Changes the name of the zip in the build target directory
                       but NOT the artifact that gets installed, deployed, releaseed -->
            <finalName>my-extra-assembly-${project.version}</finalName>
        </configuration>
    </execution>

En resumen:

1. El complemento assembly utiliza el assemblyId como el clasificador para el artefacto, por lo tanto, una parte esencial de sus coordenadas GAV únicas en maven términos (en realidad es más como coordenadas GAVC-C es el clasificador).

2. El nombre del archivo instalado, desplegado, o lanzado está construido a partir de estas coordenadas. no es el mismo que el nombre de archivo que ves en tu directorio de destino. Es por eso que su construcción local se ve bien, pero su lanzamiento fallará.

3. El elemento stupid solo determina el nombre del artefacto de construcción local y no juega ningún papel en el resto. Es un una red-herring completa.

Resumen del resumen: El error 400 de Nexus se debió a que nuestro artefacto adicional 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 esto fue larga y tortuosa path la respuesta estuvo allí todo el tiempo en los documentos de maven-assembly:

AppendAssemblyId

• Boolean

• Establecer en false para excluir el id del ensamblado del nombre final del ensamblado, y para crear el ensamblado resultante artefactos sin clasificador. Como tal, un artefacto de montaje que tiene la el mismo formato que el embalaje del actual proyecto Maven reemplazará el archivo para este proyecto principal artefacto.

• El valor predeterminado es: true.
• La propiedad de usuario es: assembly.appendAssemblyId.

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

El extra bold es mío. Los documentos deberían tener una gran advertencia intermitente aquí:"Establezca esto en falso y abandone toda esperanza"

Recibí ayuda de esta respuesta sobre un problema diferente maven-assembly-plugin: Cómo usar appendAssemblyId La explicación de Tunaki realmente ayudó.

Configuré el complemento maven release con releaseProfile=false y no ejecuté el perfil de artefactos de origen. Lo 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>