it-swarm.dev

Das Plug-In für das Release von Maven schlägt fehl: Quell-Artefakte werden zweimal bereitgestellt

Wir verwenden das maven-Release-Plugin für hudson und versuchen, den Release-Prozess zu automatisieren. Das Release: Prepare funktioniert gut. Wenn wir versuchen, das Release: perform auszuführen, schlägt es fehl, weil es versucht, ein Quellartefakt zweimal in das Repository hochzuladen.

Dinge, die ich probiert habe,

  1. entfernen des Profils, das das Maven-Source-Plugin enthält, aus dem Super-Pom (funktionierte nicht)
  2. festlegen der Ziele für hudson für die Veröffentlichung als -P! attach-source-Release: Release vorbereiten: perform. Was ich dachte, wird das Quell-Plugin von der Ausführung ausschließen. (funktioniert nicht).
  3. versuchte, die Plugin-Phase auf eine nicht vorhandene Phase im Super-Pom festzulegen (funktionierte nicht)
  4. es wurde versucht, die Plugin-Konfiguration anzugeben, forReleaseProfile als false. (weißt du was? Hat auch nicht funktioniert)

Es spuckt diesen Fehler immer noch aus.

[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

Jede Hilfe in dieser Hinsicht wird sehr geschätzt.

Versuchen Sie, mvn -Prelease-profile help:effective-pom..__ auszuführen. Sie haben zwei Ausführungsabschnitte für maven-source-plugin.

Die Ausgabe sieht ungefähr so ​​aus:

    <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>

Um dieses Problem zu beheben, suchen Sie nach allen Stellen, an denen Sie maven-source-plugin verwendet haben, und stellen Sie sicher, dass Sie die "id" attach-sources verwenden, damit diese dem Release-Profil entsprechen. Dann werden diese Abschnitte zusammengeführt.

Best Practice besagt, dass Sie, um Konsistenz zu erhalten, dies im root-POM Ihres Projekts in build> pluginManagement undNICHTin Ihren Child-Poms konfigurieren müssen. Im untergeordneten Pom legen Sie einfach in build> plugins fest, dass Sie maven-source-plugin verwenden möchten, aber keine Ausführungen.

Im Raum 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>

Im Kind pom.xml:

<build>
  <plugins>
    <plugin>
      <groupId>org.Apache.maven.plugins</groupId>
      <artifactId>maven-source-plugin</artifactId>
    </plugin>
  </plugins>
</build>
61
Bae

Ich weiß, dass diese Frage alt ist, aber heute war Google Hit # 1, und ich füge meine Antwort für die aktuellen Versionen von Maven 3 hinzu.

Das Symptom ist, dass Quellen und Javadoc-Gläser zweimal bereitgestellt werden, wenn ein Release-Build mit einigen Versionen von Maven 3 durchgeführt wird. Wenn Sie Maven verwenden, um Ihre Artefakte in einem Sonatype-Nexus-Repository bereitzustellen, in dem nur einmal ein Freigabeartefakt hochgeladen werden kann (was ist völlig vernünftiges Verhalten), schlägt der Build fehl, wenn der zweite Upload-Versuch abgelehnt wird. Argh!

Die Maven-Versionen 3.2.3 bis 3.3.9 haben Fehler - siehe https://issues.Apache.org/jira/browse/MNG-5868 und https://issues.Apache.org/jira/browse/MNG-5939 . Diese Versionen generieren und implementieren zweimal Quellen und Javadoc-Jars, wenn eine Version ausgeführt wird. 

Wenn ich den Maven-Issue-Tracker richtig gelesen habe, sind diese Fehler derzeit nicht zur Behebung geplant (die gebrannte Version 3.4.0 hat diese wahrscheinlich beeinflusst).

Anstelle eines komplexen Tweak an meinem Pom bestand mein einfacher Workaround darin, auf Maven Version 3.2.1 zurückzugreifen.

21
chrisinmtown

Nachdem ich dasselbe Problem gefunden hatte, analysierte ich es ein wenig. mvn release:perform wertet die Datei release.properties aus, checkt dann das Tag in einem temporären Verzeichnis aus und ruft dort etwas auf

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

Ich habe versucht, dies zu reproduzieren - das von release:prepare erzeugte Tag wurde manuell ausgecheckt und folgendes aufgerufen:

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

Ich habe das gleiche Ergebnis erhalten: Es wurde versucht, die Datei -sources.jar zweimal hochzuladen.

Wie in qualidafial in einem Kommentar angegeben, lässt die Einstellung von performRelease=false stattdessen einen der beiden Anhänge derselben Datei aus.

Ich habe keine Ahnung, wie das Plugin deploy (oder ein anderes Plugin) diese Eigenschaft verwendet.

Wir können diesen Parameter als Konfiguration für das Maven-Relase-Plugin bereitstellen:

<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>

Ich habe jetzt die <useReleaseProfile>false</useReleaseProfile>-Zeile zu allen POMs hinzugefügt und es sieht so aus, als ob das Freigeben jetzt ohne Fehlermeldung funktioniert.

5
Paŭlo Ebermann

Ich habe seit einiger Zeit mit diesem Problem zu kämpfen und konnte es endlich in unserer Infrastruktur lösen. Die Antworten hier haben mir nicht geholfen, da wir die Quell-Plugin-Ziele nicht mehrfach ausgeführt haben und die Konfiguration für uns in Ordnung war.

Was wir versäumt haben, war, die Ausführung des Quell-Plugins an eine Phase zu binden. Durch die Erweiterung des Beispiels um Bae einschließlich der Zeile <phase> install </ phase> auf die Ausführung wurde das Problem für uns gelöst:

<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>

Ich vermute, die Lösung liegt in dieser Antwort hier ; Verschiedene Plugins scheinen das jar-Ziel/die Attach-Sources-Ausführung aufzurufen. Indem wir unsere Ausführung an eine bestimmte Phase binden, zwingen wir unser Plugin, nur in dieser Phase ausgeführt zu werden.

3
Tobi Nonymous

Das passierte mir beim Laufen

mvn install deploy

Ich habe das Problem vermieden, indem ich weggelaufen bin

mvn deploy

(was Installation impliziert). In meinem Fall wurde nur ein Artefakt versucht, zweimal hochgeladen zu werden, und das war ein sekundäres Artefakt (das Maven-Jar-Plugin wurde so eingerichtet, dass es zusätzlich zu dem durch die Standard-Jar-Ausführung erstellten ein sekundäres Jar erstellt).

0
EricS

Ich denke nicht, dass das Problem im Release-Plugin steckt, ich glaube, Sie haben den xxx-sources.jar zweimal angehängt - deshalb ist der Duplikat-Upload. Warum ist ein doppelter Anhang schwer zu erkennen, ohne das POM zu sehen? Führen Sie mvn -X aus und überprüfen Sie das Protokoll, wer xxx-source.jar ein anderes Mal angehängt hat.

In jedem Fall wäre ein guter Workaround für Nexus ein Staging-Repository, in dem Sie Releases mehrmals hochladen können. Wenn alles fertig ist, schließen Sie das Staging-Repo. Überprüfen Sie das Sonatype OSS-Setup für ein Beispiel.

0
lexicore

FWIW diese Ausgabe brach unseren Build für eine Weile und die Antwort war keine der oben genannten. Stattdessen hatte ich die scheinbar harmlose appendAssemblyId in einem Maven-Assembly-Plugin für ein Artefakt, das mit unserem Hauptartefakt verbunden (ausgelesen, freigegeben) wird, auf false gesetzt. Z.B.:

    <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>

In Summe:

  1. das Assembly-Plugin verwendet die assemblyId als Klassifikator für das Artefakt, daher ein wesentlicher Teil seiner eindeutigen GAV-Koordinaten in Maven-Begriffen (tatsächlich ähnelt es eher den GAVC-Koordinaten - C ist der Klassifikator).

  2. der Name der Datei installiert, bereitgestellt oder freigegeben wird tatsächlich aus diesen Koordinaten erstellt. Es stimmt nicht mit dem Dateinamen überein, den Sie in Ihrem Zielverzeichnis sehen . Aus diesem Grund sieht Ihr lokaler Build gut aus, aber Ihre Veröffentlichung wird fehlschlagen.

  3. Das dumme Element bestimmt nur den Namen des lokalen Build-Artefakts und spielt im Rest keine Rolle. Es ist ein kompletter Hering.

Zusammenfassung der Zusammenfassung: Der Fehler 400 von Nexus lag daran, dass unser zusätzliches angefügtes Artefakt seitdem über das Hauptartefakt hochgeladen wurde hatte den gleichen Namen wie das Hauptartefakt, weil es die gleichen GAVC-Koordinaten wie das Hauptartefakt hatte, weil ich die einzige unterscheidende Koordinate entfernt habe: den Klassifikator, der automatisch von der Assembly-ID abgeleitet wurde.

Die Untersuchung, um dies zu finden, war ein langer und mühsamer Weg. Die Antwort war die ganze Zeit in den Dokumenten für die Maven-Versammlung richtig:

appendAssemblyId

  • Boolescher Wert

  • Setzen Sie diesen Wert auf false, um die Assembly-ID vom endgültigen Namen der Assembly auszuschließen und die resultierenden Assembly-Artefakte ohne Klassifizierer zu erstellen. Als solches ersetzt ein Assembly-Artefakt, das dasselbe Format wie das Paket des aktuellen Maven-Projekts hat, die Datei für dieses Hauptprojekt-Artefakt .

  • Der Standardwert ist: true.
  • Die Benutzereigenschaft lautet: Assembly.appendAssemblyId.

Von http://maven.Apache.org/plugins/maven-Assembly-plugin/single-mojo.html#attach

Das Extra Fett ist meins. Die Dokumente sollten hier eine große blinkende Warnung haben: "Setzen Sie dies auf falsch und geben Sie alle Hoffnung auf"

Ich habe Hilfe von dieser Antwort zu einem anderen Problem erhalten maven-Assembly-Plugin: Verwendung von appendAssemblyId Die Erklärung von tunaki dort hat wirklich geholfen.

0
Rhubarb

Ich hatte das gleiche Problem. Grundsätzlich wird die Fehlermeldung ausgegeben, wenn Artefakte zweimal an Nexus gesendet werden. Hierbei kann es sich zweimal um dasselbe Nexus-Repository oder sogar um mehrere Repositorys innerhalb desselben Nexus handeln.

Die Gründe für eine solche Fehlkonfiguration können jedoch variieren. In meinem Fall wurden die Artefakte während eines mvn-Clean-Deploy-Erstellungsschritts in Jenkins korrekt hochgeladen, scheiterten jedoch, als eine zweite Bereitstellung versucht wurde. Diese zweite Bereitstellung wurde in einem Jenkins Post Build-Schritt "Artefakte in Maven-Repository veröffentlichen" konfiguriert. 

0
not2savvy

Maven-Plugins in Eltern- und Kind-Poms sollten keine Ausführung haben. Definieren Sie gemäß der Standardkonvention alle Plugins mit Ausführung/Zielen im übergeordneten Pom im Plugin-Management-Abschnitt. Child Pom sollte die Details nicht neu definieren, sondern nur das Plugin (mit ArtifactId und Version) angeben, das ausgeführt werden muss.

Ich hatte ein ähnliches Problem mit dem Maven-Assembly-Plugin mit Eltern-Pom wie folgt:

<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>

Und Child Pom hatte ein Maven-Assembly-Plugin wie folgt:

<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>

Das Entfernen des <executions> aus dem untergeordneten Pom hat das Problem behoben. Das effektive Pom hatte zwei Ausführungen, die die doppelte Installation auf Nexus repo verursachten.

0
Amit Kaneria