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

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.

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.

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.

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

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.

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.

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. 

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.