plugin de Maven liberación falla: los artefactos de origen conseguir desplegaron dos veces

Question

Estamos utilizando el plugin de liberación experto en Hudson y tratando de automatizar el proceso de liberación. La liberación: preparar trabajos bien. Cuando tratamos de hacer la remisión:. Cabo, como un error porque intenta cargar un artefacto fuente dos veces al repositorio

Las cosas que he intentado,

1. retirar el perfil que hace incluir el plugin fuente experto de la pom super (no funcionaba)
2. especificando los objetivos de Hudson para la liberación como -P attach-fuente de liberación: liberación de preparar: realizar. Lo cual pensé que excluirá el plugin fuente de la silla eléctrica. (No funcionaba).
3. intentado especificando la fase plugin para alguna fase inexistente en el súper pom. (No funcionaba)
4. intentado especificando la configuración plugin, forReleaseProfile como falso. (¿De qué ?? no funcionó demasiado)

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á muy apreciado.

Answer 1

Trate de ejecutar mvn -Prelease-profile help:effective-pom. Usted encontrará que usted tiene dos secciones de ejecución para maven-source-plugin

La salida será 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, encontrar por todas partes usted tiene maven-source-plugin utilizados y asegúrese de que se utiliza el "id" attach-fuentes, de manera que es el mismo que el perfil de liberación. A continuación, se fusionarán estas secciones.

La mejor práctica dice que para conseguir la consistencia necesaria para configurar esto en el POM raíz del proyecto de construcción> pluginManagement y no en su hijo poms. En el pom niño que acaba de especificar en la construcción> plugins que desee utilizar maven-fuente-plugin sino que proporcionas ninguna ejecución.

En la sala de pom.xml:

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-source-plugin</artifactId>
        <executions>
          <execution>
            <!-- This id must match the -Prelease-profile id value or else sources will be "uploaded" twice, which causes Nexus to fail -->
            <id>attach-sources</id>
            <goals>
              <goal>jar</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>    
  </pluginManagement>
</build>

En el pom.xml niño:

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

Answer 2

Sé que esta pregunta es viejo pero era Google alcanzó el # 1 hoy así que voy a añadir mi apropiada respuesta para las versiones recientes de Maven 3.

El síntoma es que las fuentes y los tarros javadoc se despliegan dos veces cuando se hace una versión de lanzamiento con algunas versiones del experto 3. Si está utilizando Maven para desplegar sus artefactos a un repositorio Sonatype Nexus que sólo permite un artefacto de liberación para ser subido una vez (que es un comportamiento totalmente razonable), la generación falla cuando se rechaza el segundo intento de carga. Argh!

Maven versiones 3.2.3 a través de 3.3.9 tienen errores - ver https: // cuestiones .apache.org / jira / Navegar / MNG-5868 y https: // issues.apache.org/jira/browse/MNG-5939 . Esas versiones generan y despliegan las fuentes y tarros javadoc dos veces al hacer un lanzamiento.

Si leo el seguimiento de incidencias Maven correctamente, esos errores no se programan para el arreglo de este escrito (la quema 3.4.0 liberación probablemente afectada éstos).

En lugar de un pellizco complejo a mi pom, mi sencilla solución fue a caer de nuevo a Maven versión 3.2.1.

Answer 3

Sólo tener éxito el mismo problema, que analiza un poco. mvn release:perform evalúa el archivo release.properties, a continuación, comprueba fuera de la etiqueta en un directorio temporal e invoca Hay 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

He intentado reproducir este - manualmente comprobado la etiqueta producida por release:prepare e invocado esto:

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

Me dieron el mismo resultado: Se trataba de cargar el doble de -sources.jar

.

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

Yo realmente no tienen una idea de cómo el desplegar plug-in (o cualquier otro plugin) utiliza esta propiedad.

Nos puede proporcionar este parámetro como una configuración a la 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 añadí la línea <useReleaseProfile>false</useReleaseProfile> a todas las POM, y parece que ahora funciona sin soltar un mensaje de error.

Answer 4

He estado struggeling con este tema por un tiempo y finalmente he podido resolverlo en nuestra infraestructura. Las respuestas aquí no me ayuda, ya que no dispone de varias ejecuciones de la fuente del plugin objetivos y la configuración parecía bien a nosotros.

Lo que se perdiera iba a obligar a la ejecución del plug-in de origen a una fase. Extendiendo el ejemplo por Bae, incluyendo la línea instalar para la ejecución resuelve 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 las mentiras de soluciones en esta respuesta aquí ; diferentes plugins parecen estar invocando el objetivo jar / la ejecución attach-fuentes. Al unirse a nuestra ejecución una cierta fase, forzamos nuestro plugin sólo para ser ejecutado en esta fase.

Answer 5

Esto me sucedía cuando se ejecuta

mvn install deploy

Me evita el problema en lugar de correr

mvn deploy

(lo que implica instalar). En mi caso estaba siendo intentar sólo un artefacto para ser subido dos veces, y que era un artefacto secundario (maven-jar-plugin fue instalado para construir un frasco en forma adicional a la construida por la ejecución default-jar).

Answer 6

No creo que el problema tomando está en el plugin de liberación, creo que tienes los xxx-sources.jar adjunta 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. Pruebe a ejecutar mvn -X y comprobar el registro para que los agregados xxx-source.jar otra vez.

En cualquier caso, una buena solución en Nexus sería tener un repositorio puesta en escena donde puede cargar libera varias veces - y cuando esté listo que acaba de cerrar / promover la puesta en escena de recompra de todo. Compruebe el Sonatype OSS configuración para un ejemplo.

Answer 7

Yo tenía el mismo problema. Básicamente, el mensaje de error se emite cuando un artefactos se envía a Nexus dos veces. Esto puede ser dos veces para el mismo repositorio Nexus o incluso a través de diferentes repositorios dentro de la misma Nexus.

Sin embargo, las razones de tal una mala configuración pueden variar. En mi caso, los artefactos se han subido correctamente durante una etapa de despliegue generación limpia mvn en Jenkins, pero no cuando un segundo despliegue se había intentado. Este segundo despliegue se ha configurado en un paso posterior a la acumulación Jenkins "Publicar artefactos en repositorio de Maven".

Answer 8

Maven plugins en padre e hijo no debería tener poms ejecución. De acuerdo con la convención estándar, definir todas plugin con ejecución / goles en pom de los padres en la sección de gestión de plugins. pom niño no debe redefinir por encima de los detalles, pero por mencionar sólo el plugin (con artifactId, y la versión) que debe ser ejecutado.

he tenido problema similar con Maven-montaje-pom plugin con los padres 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>

pom

Y Niño había maven-montaje-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>

Extracción de la <executions> del pom niño rectificar el problema. El POM efectiva tenía 2 ejecuciones realizadas causando el duplicado a instalar Nexus cesión temporal.

Answer 9

Fwiw este tema estaba rompiendo nuestra construcción por un tiempo y la respuesta fue que ninguno-of-the-arriba. En su lugar me había propuesto tontamente la aparentemente inocua appendAssemblyId en false en un experto en montaje-Plugin para un artefacto que se apega (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. los usos de montaje plugin de la assemblyId como el clasificador para el artefacto, por lo tanto, una parte esencial de su 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 , desplegados o lanzado es en realidad construida a partir de estas coordenadas. Es no es el mismo que el nombre del archivo que aparece en el directorio de destino . Es por eso que su construcción locales se ve bien, pero su lanzamiento se producirá un error.

3. El elemento estúpida sólo determina el nombre de la Estructura artefacto local y no juega ningún papel en el resto de la misma. Es una pista falsa completa.

Resumen del resumen: El error 400 del Nexus fue porque nuestro artefacto adjunta adicional estaba siendo cargado sobre la parte superior del artefacto principal, ya que tenía el mismo nombre que el artefacto principal, porque tenía las mismas coordenadas GAVC como el artefacto principal, porque me quita la única distinguir de coordenadas:. el clasificador deriva automáticamente de la assemblyId

La investigación para encontrar esto era un camino largo y tortuoso la respuesta estaba allí todo el tiempo en la documentación para maven-ensamblaje:

  

appendAssemblyId

     

  

• boolean

  

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

  
• El valor por defecto es:. True
  
• propiedad de usuario es:. Assembly.appendAssemblyId
  

http: //maven.apache. org / plugins / maven-montaje-plugin / de un solo mojo.html # conceden

La negrita es mía adicional. Los documentos deben tener un gran intermitente de advertencia aquí: "Establecer esto a falso y abandonar toda esperanza"

Tengo un poco de ayuda de esta respuesta acerca de un problema diferente Maven-montaje-plugin: Cómo utilizar appendAssemblyId La explicación allí desde tunaki realmente ayudó.

Answer 10

I configurado la liberación experto plug-in con releaseProfile = false Y no ejecutar el perfil artefactos de origen. ¿Qué 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>