Maven: Die Verpackung für dieses Projekt hat dem Build -Artefakt keine Datei zugewiesen

https://stackoverflow.com/questions/6308162

26-10-2019
|

Frage

Ich verwende Maven 3.0.3 auf Mac 10.6.6. Ich habe ein JAR -Projekt und wenn ich den Befehl "MVN Clean Install: Installation" ausführe, erhalte ich den Fehler.

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:2.3.1:install (default-cli) on project StarTeamCollisionUtil: The packaging for this project did not assign a file to the build artifact -> [Help 1]

Was bedeutet das und wie kann ich es beheben? Unten ist mein pom.xml. Lassen Sie mich wissen, welche anderen Informationen hilfreich sind, und ich werde diesen Beitrag bearbeiten. Danke, - Dave

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.myco.starteam.util</groupId>
<artifactId>StarTeamCollisionUtil</artifactId>
<packaging>jar</packaging>
<name>StarTeam Collision Util</name>
<description>
    The StarTeam Collision Utility provides developers and release engineers alike the ability to
    compare files attached to a set of CRs to see if conflicts exist in the change set.
</description>
<version>1.0-SNAPSHOT</version>
<url>http://cm-build.myco.com:8080/hudson/view/Tools/job/StarTeamCollisionUtil - TRUNK/</url>
<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<repositories>
    <repository>
        <id>myco-sonatype-nexus-snapshots</id>
        <name>MyCo Sonatype-Nexus Snapshots</name>
        <url>http://sonatype.myco.com/nexus/content/repositories/snapshots/</url>
    </repository>
</repositories>
<dependencies>
    <dependency>
        <groupId>starteam</groupId>
        <artifactId>starteam</artifactId>
        <version>1.1.0</version>
        <type>jar</type>
        <scope>system</scope>
        <systemPath>${basedir}/lib/starteam110.jar</systemPath>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.8.2</version>
    </dependency>
    <dependency>
        <groupId>org.apache.ant</groupId>
        <artifactId>ant</artifactId>
        <version>1.8.1</version>
    </dependency>
    <dependency>
        <groupId>javax.mail</groupId>
        <artifactId>mail</artifactId>
        <version>1.4.1</version>
        <type>jar</type>
        <scope>compile</scope>
    </dependency>
</dependencies>
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.8.1</version>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-site-plugin</artifactId>
            <version>3.0-beta-3</version>
            <configuration>
                <reportPlugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-report-plugin</artifactId>
                        <version>2.5</version>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                        <version>2.7</version>
                        <configuration>
                            <linksource>true</linksource>
                        </configuration>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-jxr-plugin</artifactId>
                        <version>2.2</version>
                    </plugin>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>versions-maven-plugin</artifactId>
                        <version>1.2</version>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-project-info-reports-plugin</artifactId>
                        <version>2.3.1</version>
                        <reportSets>
                            <reportSet>
                                <reports>
                                    <report>index</report>
                                    <report>dependencies</report>
                                    <report>dependency-management</report>
                                    <report>cim</report>
                                    <report>issue-tracking</report>
                                    <report>license</report>
                                    <report>scm</report>
                                </reports>
                            </reportSet>
                        </reportSets>
                    </plugin>
                </reportPlugins>
            </configuration>
        </plugin>
    </plugins>
</build>
<distributionManagement>
    <repository>
        <id>sonatype-nexus</id>
        <url>http://sonatype.myco.com/nexus/content/repositories/snapshots/</url>
    </repository>
</distributionManagement>
<scm>
    <url>https://starteam.cmass.myco.com/BorlandStarTeam/BorlandStarTeam.jsp</url>
</scm>
<issueManagement>
    <system>StarTeam</system>
    <url>https://starteam.cmass.myco.com/BorlandStarTeam/BorlandStarTeam.jsp</url>
</issueManagement>
<ciManagement>
    <system>Hudson</system>
    <url>http://cm-build.myco.com:8080/hudson/</url>
</ciManagement>
</project>

Lösung

Ich weiß nicht, ob dies die Antwort ist oder nicht, aber es könnte Sie in die richtige Richtung führen ...

Der Befehl install:install ist eigentlich ein Ziel auf der Maven-Installation-Plugin. Dies ist anders als die install Maven -Lebenszyklusphase.

Maven -Lebenszyklusphasen sind Schritte in einem Build, an die sich bestimmte Plugins selbst binden können. Viele verschiedene Ziele aus verschiedenen Plugins können ausgeführt werden, wenn Sie eine einzelne Lebenszyklusphase aufrufen.

Worauf läuft das an, ist der Befehl ...

mvn clean install

unterscheidet sich von...

mvn clean install:install

Ersteres wird in jedem Zyklus vor und einschließlich der Installation alle Ziele veranstalten (wie Compile, Package, Test usw.). Letzteres kompiliert oder verpackt nicht einmal Ihren Code, er wird nur dieses ein Ziel ausgeführt. Das macht Sinn und betrachtet die Ausnahme; es redet über:

StarteAmCollisionUtil: Die Verpackung für dieses Projekt hat dem Build -Artefakt keine Datei zugewiesen

Probieren Sie erstere aus und Ihr Fehler könnte einfach verschwinden!

Andere Tipps

Tl; dr Um dieses Problem zu beheben, rufen Sie vorher ein Verpackungs -Plugin ein, z. B. für jar Verpackung Gebrauch maven-jar-plugin , wie folgt:

mvn jar:jar install:install

Oder

mvn jar:jar deploy:deploy

Wenn Sie tatsächlich einsetzen mussten.

Erwischt Dieser Ansatz funktioniert nicht, wenn Sie ein Multi-Modul-Projekt mit verschiedenen Packungen (Ohr/Krieg/Jar/ZIP) haben-noch schlimmer, falsche Artefakte werden installiert/bereitgestellt! Verwenden Sie in diesem Fall Reaktoroptionen, um das bereitstellbare Modul nur zu erstellen (z. B. die war).

Erläuterung

In einigen Fällen möchten Sie tatsächlich direkt a install:install oder deploy:deploy Ziel (dh von der maven-deploy-plugin, das deploy Ziel, nicht der Maven deploy Phase) und du würdest im nervigen enden The packaging for this project did not assign a file to the build artifact.

Ein klassisches Beispiel ist ein CI -Job (ein Jenkins- oder Bambusjob, z. B.), bei dem Sie sich in verschiedenen Schritten für verschiedene Aspekte ausführen/pflegen möchten:

Ein erster Schritt wäre ein mvn clean install, Tests und Testabdeckung durchführen
Ein zweiter Schritt wäre eine Sonarqube -Analyse, die auf einem Qualitätsprofil basiert, z. B. mvn sonar:sonar Plus weitere Optionen
Dann und erst nach erfolgreichen Tests Ausführung und Qualitätsgatter möchten Sie in Ihrem Maven Enterprise-Repository die endgültigen Projektartefakte bereitstellen, aber Sie möchten jedoch nicht erneut fahren mvn deploy, weil es wieder frühere Phasen ausführen würde (und kompilieren, testen usw.) und Sie möchten, dass Ihr Build effektiv ist, aber dennoch schnell.

Ja, Sie können diesen letzten Schritt beschleunigen, zumindest überspringen Tests (Zusammenstellung und Ausführung, über -Dmaven.test.skip=true) oder mit einem bestimmten Profil spielen (um so viele Plugins wie möglich zu überspringen), aber es ist viel einfacher und klar, einfach zu laufen mvn deploy:deploy dann.

Aber es würde mit dem obigen Fehler fehlschlagen, denn wie auch angegeben durch das Plugin -FAQ:

Während der Verpackungsphase alle gesammelt und im Kontext gestellt. Mit diesem Mechanismus kann Maven sicherstellen, dass die maven-install-plugin und maven-deploy-plugin kopieren/laden dieselben Dateien hoch. Also, wenn Sie nur ausführen deploy:deploy, und dann gibt es keine Dateien im Kontext und es gibt nichts zu bieten.

In der Tat das deploy:deploy Benötigt einige Laufzeitinformationen, die im Build -Kontext nach früheren Phasen (oder früheren Plugins/Toren -Ausführungen) platziert sind.

Es hat auch als potenzieller Fehler berichtet: MDEPLOY-158: Bereitstellung: Der Einsatz funktioniert nicht nur für das Bereitstellen von Artefakten für Maven Remote Repo

Aber dann als kein Problem abgelehnt.

Das deployAtEnd Konfigurationsoption der maven-deploy-plugin Ich werde weder in bestimmten Szenarien helfen, da wir Zwischenberufungsschritte zum Ausführen haben:

Unabhängig davon, ob jedes Projekt während seiner eigenen Bereitstellungsphase oder am Ende des Multimodul-Builds eingesetzt werden sollte. Wenn auf true und der Build scheitert, keines der Reaktorprojekte wird eingesetzt. (Experimental)

Also, wie kann man es beheben?
Führen Sie einfach Folgendes in einem ähnlichen dritten/letzten Schritt aus:

mvn jar:jar deploy:deploy

Das maven-jar-plugin dank seiner wird kein Glas als Teil Ihres Builds neu erstellen forceCreation Option eingestellt auf false standardmäßig:

Erfordern Sie das JAR -Plugin, ein neues Glas zu bauen, auch wenn sich keiner der Inhalte geändert hat. Standardmäßig ist dieses Plugin zu sehen, ob das Ausgabeglas existiert und die Eingänge nicht geändert haben. Wenn diese Bedingungen wahr sind, überspringt das Plugin die Erstellung des Glass.

Aber es wird den Build -Kontext für uns gut bevölkern und machen deploy:deploy glücklich. Keine Tests zu überspringen, keine Profile hinzuzufügen. Genau das, was Sie brauchen: Geschwindigkeit.

Zusätzlicher Hinweis: Wenn Sie die verwenden build-helper-maven-plugin, buildnumber-maven-plugin oder ein anderes ähnliches Plugin, um eine Meta-Daten zu erzeugen, die später von der verwendet wird maven-jar-plugin (ZB ein Einträge für die Manifest -Datei) Sie haben höchstwahrscheinlich Ausführungen mit dem verknüpft validate Phase und Sie möchten sie immer noch während der jar:jar Schritt erstellen (und führen Sie dennoch eine schnelle Ausführung). In diesem Fall besteht der fast harmlose Overhead darin, das aufzurufen validate Phase wie folgt:

mvn validate jar:jar deploy:deploy

Ein weiterer zusätzlicher Hinweis: Wenn Sie nicht haben jar Aber sagen Sie, sagen Sie war Verpackung, Verwendung war:war Vor der Installation/Bereitstellung stattdessen.

Erwischt Überprüfen Sie, wie oben erwähnt, das Verhalten in Multi -Modul -Projekten.

Diese Antwort ist auf eine sehr alte Frage, um anderen zu helfen, sich diesem Problem zu stellen.

Ich bin diesem fehlgeschlagenen Fehler, während ich an meinem arbeitete Java Projekt verwenden IntelliJ IDEA Ide.

Failed to execute goal org.apache.maven.plugins:maven-install-plugin:2.4:install (default-cli) on project getpassword: The packaging for this project did not assign a file to the build artifact

Dies ist fehlgeschlagen, wenn ich wähle install:install unter Plugins - install, wie mit rotem Pfeil im folgenden Bild gezeigt.

Sobald ich die ausgewählte betrieben habe install unter Lifecycle Wie oben dargestellt, verschwand das Problem und mein Maven -Installations -Compile -Build erfolgreich.

Ich habe das gleiche Problem. Die Fehlermeldung für mich ist nicht vollständig. Aber in meinem Fall habe ich Generation Jar mit Quellen hinzugefügt. Durch Platzieren dieses Codes in pom.xml:

<build> 
    <pluginManagement>
        <plugins>
            <plugin>
                <artifactId>maven-source-plugin</artifactId>
                <version>2.1.2</version>
                <executions>
                    <execution>
                        <phase>deploy</phase>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

In der Bereitstellung von Phase I Execute Source: JAR -Ziel, das JAR mit Quellen produziert. Und der Einsatz endet mit dem Erstellungserfolg

Sie müssen die Zieldatei löschen, z.

Ich hatte das gleiche Problem, aber ich habe ausgeführt MVN Installation anfangs (nicht Installation: Installieren wie es bereits erwähnt wurde).

Die Lösung besteht darin,: Folgendes einzuschließen:

 <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-install-plugin</artifactId>
        <version>2.5.2</version>
 </plugin>

In den Abschnitt "Plugin Management".

Dieser Fehler zeigt sich bei der Verwendung der Maven-Install-Plugin-Version 3.0.0-m1 (oder ähnlich)

Wie bereits oben und auch hier mentiokt, funktioniert die folgende Plug-in-Version:

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-install-plugin</artifactId>
        <version>2.5.2</version>
    </plugin>

Während @a_di-matteo Antwort für Non-Multimodule funktioniert, habe ich eine Lösung für Multimoduli.

Die Lösung besteht darin, jede Plugin -Konfiguration so zu überschreiben, dass sie an die Phase von bindet none Mit Ausnahme des JAR-/Kriegs-/Ohr -Plugin und natürlich des Bereitstellungs -Plugins. Auch wenn Sie ein einzelnes Modul haben, zeigen meine rudimentären Tests, dass dies etwas schneller ist (aus Gründen, die ich nicht kenne).

Der Trick besteht daher darin, ein Profil zu erstellen, das das oben genannte Aktivitäten durchführt, wenn Sie nur bereitstellen möchten.

Im Folgenden finden Sie ein Beispiel eines meiner Projekte, bei dem das Schatten-Plugin verwendet wird. Daher musste ich das JAR-Plugin erneut übergeben, um nicht zu überschreiben:

    <profile>
      <id>deploy</id>
      <activation>
        <property>
          <name>buildStep</name>
          <value>deploy</value>
        </property>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <executions>
              <execution>
                <id>default-compile</id>
                <phase>none</phase>
              </execution>
              <execution>
                <id>default-testCompile</id>
                <phase>none</phase>
              </execution>
              <execution>
                <id>test-compile</id>
                <phase>none</phase>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <executions>
              <execution>
                <id>default-test</id>
                <phase>none</phase>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <executions>
              <execution>
                <id>default-install</id>
                <phase>none</phase>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-resources-plugin</artifactId>
            <executions>
              <execution>
                <id>default-resources</id>
                <phase>none</phase>
              </execution>
              <execution>
                <id>default-testResources</id>
                <phase>none</phase>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <executions>
              <execution>
                <id>default</id>
                <phase>none</phase>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <executions>
              <execution>
                <id>default-jar</id>
                <configuration>
                  <forceCreation>false</forceCreation>
                </configuration>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>

Jetzt, wenn ich renne mvn deploy -Pdeploy Es wird nur das Glas ausgeführt und Plugins bereitgestellt.

Wie Sie herausfinden können, welche Plugins Sie überschreiben müssen, besteht darin, die Bereitstellung auszuführen und das Protokoll anzusehen, um zu sehen, welche Plugins ausgeführt werden. Stellen Sie sicher, dass Sie das im Auge behalten id der Plugin -Konfiguration, die nach dem Namen des Plugins Parens ist.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow