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

Ich verwende Maven 3.0.3 auf Mac 10.6.6. Ich habe ein JAR-Projekt und wenn ich den Befehl "mvn clean install: install" 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 das beheben? Unten ist meine pom.xml. Lassen Sie mich wissen, welche anderen Informationen hilfreich wären 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>

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

Der Befehl install:installist eigentlich ein Ziel im maven-install-plugin . Dies unterscheidet sich von der installMaven-Lebenszyklusphase.

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

Worauf es ankommt, ist der Befehl ...

mvn clean install

unterscheidet sich von...

mvn clean install:install

Ersteres führt alle Ziele in jedem Zyklus vor und einschließlich der Installation aus (wie Kompilieren, Paketieren, Testen usw.). Letzterer kompiliert oder verpackt Ihren Code nicht einmal, sondern führt nur dieses eine Ziel aus. Das macht irgendwie Sinn, wenn man die Ausnahme betrachtet; es redet über:

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

Versuchen Sie das erstere und Ihr Fehler könnte einfach verschwinden!

TL; DR Um dieses Problem zu beheben, rufen Sie das Verpackungs-Plugin vorher auf, z. B. zur jarVerwendung maven-jar-pluginals Verpackung :

mvn jar:jar install:install

Oder

mvn jar:jar deploy:deploy 

Wenn Sie tatsächlich bereitstellen mussten.

Gotcha Dieser Ansatz funktioniert nicht, wenn Sie ein Projekt mit mehreren Modulen und unterschiedlichen Verpackungen (Ohr / Krieg / Glas / Reißverschluss) haben - noch schlimmer, es werden falsche Artefakte installiert / bereitgestellt! Verwenden Sie in diesem Fall Reaktoroptionen, um nur das bereitstellbare Modul (z war. B. das ) zu erstellen .

Erläuterung

In einigen Fällen möchten Sie tatsächlich direkt ein install:installoder ein deploy:deployZiel ausführen (dh aus maven-deploy-plugindem deployZiel, nicht aus der Maven- deploy Phase ), und Sie würden in der nervigen Situation enden The packaging for this project did not assign a file to the build artifact.

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

• Ein erster Schritt wäre die mvn clean installDurchführung von Tests und die Testabdeckung
• Ein zweiter Schritt wäre eine Sonarqube-Analyse basierend auf einem Qualitätsprofil, z. B. mvn sonar:sonarplus weiteren Optionen
• Dann und erst nachdem die erfolgreiche Testausführung und das Quality Gate bestanden wurden, möchten Sie die endgültigen Projektartefakte in Ihrem Maven-Unternehmensrepository bereitstellen, aber nicht mvn deployerneut ausführen, da die vorherigen Phasen erneut ausgeführt (und kompiliert, getestet) werden usw.) und Sie möchten, dass Ihr Build effektiv und dennoch schnell ist .

Ja, Sie könnten diesen letzten Schritt beschleunigen, indem Sie zumindest Tests überspringen (Kompilieren und Ausführen, via -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 klarer, sie mvn deploy:deploydann einfach auszuführen .

Aber es würde mit dem obigen Fehler fehlschlagen, da, wie auch in den Plugin-FAQ angegeben :

Während der Verpackungsphase wurden alle gesammelt und in einen Kontext gestellt. Mit diesem Mechanismus kann Maven sicherstellen, dass maven-install-pluginund maven-deploy-plugindieselben Dateien kopieren / hochladen. Wenn Sie also nur ausführen deploy:deploy, werden keine Dateien in den Kontext gestellt und es muss nichts bereitgestellt werden.

In der Tat deploy:deploywerden einige Laufzeitinformationen benötigt , die von früheren Phasen (oder früheren Plugins / Zielausführungen) in den Build-Kontext gestellt wurden.

Es wurde auch als potenzieller Fehler gemeldet :: MDEPLOY-158Bereitstellen: Bereitstellen funktioniert nicht nur für das Bereitstellen von Artefakten für Maven Remote Repo

Aber dann als kein Problem abgelehnt.

Die deployAtEndKonfigurationsoption von maven-deploy-pluginhilft auch in bestimmten Szenarien nicht weiter, da wir Zwischenjobschritte ausführen müssen:

Ob jedes Projekt während seiner eigenen Bereitstellungsphase oder am Ende des Multimodul-Builds bereitgestellt werden soll. Wenn gesetzt trueund der Build fehlschlägt, wird keines der Reaktorprojekte bereitgestellt. (Experimental)

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

mvn jar:jar deploy:deploy

Das maven-jar-pluginwird nicht neu erstellen jedes Glas als Teil des Build dank seiner forceCreationOption auf falsestandardmäßig:

Fordern Sie das JAR-Plugin an, um eine neue JAR zu erstellen, auch wenn sich anscheinend keiner der Inhalte geändert hat. Standardmäßig prüft dieses Plugin, ob das Ausgabeglas vorhanden ist und sich die Eingaben nicht geändert haben. Wenn diese Bedingungen erfüllt sind, überspringt das Plugin die Erstellung des JARs.

Aber es wird den Build-Kontext für uns gut füllen und deploy:deployglücklich machen . Keine Tests zum Überspringen, keine Profile zum Hinzufügen. Genau das, was Sie brauchen: Geschwindigkeit.

Zusätzlicher Hinweis: Wenn Sie die verwenden build-helper-maven-plugin, buildnumber-maven-pluginoder andere ähnliche Plug - Meta-Daten zu erzeugen , später durch die verwendete maven-jar-plugin(zB Einträge für die Manifest - Datei), Sie höchstwahrscheinlich Ausführungen zu der verknüpften haben validatePhase und Sie wollen immer noch , sie haben während den jar:jarBuild-Schritt (und dennoch eine schnelle Ausführung beibehalten). In diesem Fall besteht der nahezu harmlose Overhead darin, die validate Phase wie folgt aufzurufen :

mvn validate jar:jar deploy:deploy

Noch eine weitere zusätzliche Anmerkung: wenn Sie nicht haben , jarsondern, sagen wir, warVerpackung, Verwendung war:warvor der Installation / deploy statt.

Gotcha, wie oben erwähnt, überprüfen Sie das Verhalten in Projekten mit mehreren Modulen.

Diese Antwort bezieht sich auf eine sehr alte Frage, um anderen zu helfen, die mit diesem Problem konfrontiert sind.

Ich habe diesen Fehler festgestellt, als ich Javamit IntelliJ IDEAIDE an meinem Projekt gearbeitet habe .

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 install:installunter wähle Plugins - install, wie mit dem roten Pfeil im Bild unten gezeigt.

Sobald ich das ausgewählte installunter Lifecyclewie oben dargestellt ausgeführt habe, ist das Problem behoben und meine Maven-Installation wurde erfolgreich kompiliert.

Ich habe das gleiche Problem. Die Fehlermeldung für mich ist nicht vollständig. Aber in meinem Fall habe ich Generationsglas 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 Bereitstellungsphase führe ich das Ziel source: jar aus, das jar mit Quellen erzeugt. Die Bereitstellung endet mit BUILD SUCCESS

Sie müssen die Zieldatei löschen, z. B. in jar und anderen. In C: Fahren Sie Ihren Ordner auf .m2. Sehen Sie sich den Speicherort an, an dem die JAR-Datei, die Snaphot-Datei installiert und gelöscht werden. Löschen Sie dann die Anwendung, von der Sie festgestellt haben, dass sie ausgeführt wird

Dieser Fehler tritt auf, wenn Sie das maven-install-plugin Version 3.0.0-M1 (oder ähnliches) verwenden.

Wie oben bereits erwähnt und auch hier 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 die Antwort @ A_Di-Matteo für Nicht-Multimodule funktioniert, habe ich eine Lösung für Multimodule.

Die Lösung besteht darin, jede Plugin-Konfiguration so zu überschreiben, dass sie nonemit Ausnahme des jar / war / ear-Plugins und natürlich des Bereitstellungs-Plugins an die Phase von gebunden ist. Selbst wenn Sie ein einzelnes Modul haben, zeigen meine rudimentären Tests, dass dies in Bezug auf die Leistung etwas schneller ist (aus Gründen, die ich nicht kenne).

Daher besteht der Trick darin, ein Profil zu erstellen, das die oben genannten Funktionen ausführt und aktiviert wird, wenn Sie nur bereitstellen möchten.

Unten ist ein Beispiel aus einem meiner Projekte, das das Schatten-Plugin verwendet. Daher musste ich das JAR-Plugin erneut überschreiben, um es 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>

Wenn ich jetzt starte mvn deploy -Pdeploy, wird nur das JAR ausgeführt und Plugins bereitgestellt.

Um herauszufinden, welche Plugins Sie überschreiben müssen, müssen Sie die Bereitstellung ausführen und im Protokoll nachsehen, welche Plugins ausgeführt werden. Vergewissern Sie sich, dass Sie iddie Plugin-Konfiguration nach dem Namen des Plugins im Auge behalten .

Ich hatte das gleiche Problem, aber ich habe mvn install anfangs ausgeführt (nicht install: install wie zuvor erwähnt).

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 Plugin-Management-Bereich.