Maven: opakowanie dla tego projektu nie przypisało pliku do artefaktu kompilacji


113

Używam Maven 3.0.3 na Macu 10.6.6. Mam projekt JAR i po uruchomieniu polecenia „mvn clean install: install” pojawia się błąd,

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

Co to oznacza i jak mogę to naprawić? Poniżej znajduje się mój pom.xml. Daj mi znać, jakie inne informacje byłyby pomocne, a zmodyfikuję ten post. Dzięki, - 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>

Odpowiedzi:


168

Nie wiem, czy to jest odpowiedź, czy nie, ale może poprowadzić cię we właściwym kierunku ...

Polecenie install:installjest w rzeczywistości celem wtyczki maven-install-plugin . Różni się to od installfazy cyklu życia twórcy.

Fazy ​​cyklu życia Mavena to etapy kompilacji, z którymi mogą się wiązać niektóre wtyczki. Po wywołaniu pojedynczej fazy cyklu życia może zostać zrealizowanych wiele różnych celów z różnych wtyczek.

Sprowadza się to do polecenia ...

mvn clean install

jest inny od...

mvn clean install:install

Pierwsza z nich będzie uruchamiać wszystkie cele w każdym cyklu poprzedzającym instalację (np. Kompilacja, pakiet, test itp.). Ten ostatni nawet nie skompiluje ani nie spakuje twojego kodu, po prostu uruchomi ten jeden cel. To ma sens, patrząc na wyjątek; Mówi o tym:

StarTeamCollisionUtil: opakowanie dla tego projektu nie przypisało pliku do artefaktu kompilacji

Spróbuj tego pierwszego, a błąd może po prostu zniknąć!



96

TL; DR Aby rozwiązać ten problem, wywołaj wcześniej wtyczkę pakowania, np. Do jarużycia w pakiecie maven-jar-plugin, w następujący sposób:

mvn jar:jar install:install

Lub

mvn jar:jar deploy:deploy 

Jeśli faktycznie musisz wdrożyć.

Gotcha To podejście nie zadziała, jeśli masz projekt wielomodułowy z różnymi pakietami (ear / war / jar / zip) - co gorsza, zostaną zainstalowane / wdrożone niewłaściwe artefakty! W takim przypadku użyj opcji reaktora, aby zbudować tylko moduł do rozmieszczania (np. war).


Wyjaśnienie

W niektórych przypadkach rzeczywiście chcesz uruchomić bezpośrednio install:installlub deploy:deploycel (czyli od maven-deploy-pluginThe deploycel, a nie Maven deploy faza ) i skończy się irytujące The packaging for this project did not assign a file to the build artifact.

Klasycznym przykładem jest zadanie CI (np. Praca Jenkinsa lub Bamboo), w której na różnych etapach chcesz wykonać / dbać o różne aspekty:

  • Pierwszym krokiem byłoby mvn clean installwykonanie testów i pokrycie testów
  • Drugim krokiem byłaby analiza Sonarqube oparta na profilu jakości, np. mvn sonar:sonarPlus dodatkowe opcje
  • Następnie, i dopiero po pomyślnym wykonaniu testów i przejściu bramki jakości, chcesz wdrożyć w repozytorium przedsiębiorstwa Maven ostateczne artefakty projektu, ale nie chcesz uruchamiać ponownie mvn deploy, ponieważ ponownie wykonałby poprzednie fazy (i skompilował, przetestował itp.) i chcesz, aby Twoja kompilacja była skuteczna, ale jednocześnie szybka .

Tak, możesz przyspieszyć ten ostatni krok przynajmniej pomijając testy (kompilację i wykonanie, przez -Dmaven.test.skip=true) lub grać z określonym profilem (aby pominąć jak najwięcej wtyczek), ale wtedy jest o wiele łatwiejsze i przejrzyste, aby po prostu uruchomić mvn deploy:deploy.

Ale to się nie powiedzie z powyższym błędem, ponieważ jak również określono w FAQ wtyczki :

Podczas fazy pakowania wszystko zostało zebrane i umieszczone w kontekście. Dzięki temu mechanizmowi Maven może zapewnić, że maven-install-plugini maven-deploy-pluginkopiują / przesyłają ten sam zestaw plików. Więc kiedy tylko wykonujesz deploy:deploy, nie ma plików umieszczanych w kontekście i nie ma nic do wdrożenia.

Rzeczywiście, deploy:deploypotrzebne są pewne informacje dotyczące środowiska uruchomieniowego umieszczone w kontekście kompilacji przez poprzednie fazy (lub poprzednie wykonania wtyczek / celów).

Zgłoszono również jako potencjalny błąd:: MDEPLOY-158wdrażanie: wdrażanie nie działa tylko w przypadku wdrażania artefaktu w repozytorium Maven Remote

Ale potem odrzucony jako nie problem.

Opcja deployAtEndkonfiguracji maven-deploy-pluginnie pomoże w niektórych scenariuszach, ponieważ mamy do wykonania pośrednie kroki zadania:

Czy każdy projekt powinien zostać wdrożony podczas jego własnej fazy wdrażania, czy na końcu budowy multimodułu. Jeśli jest ustawiona na truei kompilacja nie powiedzie się, żaden z projektów reaktora nie zostanie wdrożony. (eksperymentalny)

Jak więc to naprawić?
Po prostu uruchom następujące w podobnym trzecim / ostatnim kroku:

mvn jar:jar deploy:deploy

maven-jar-pluginNie będzie ponownie utworzyć dowolną słoik jako część swojej produkcji, dzięki swoim forceCreationzestawie opcja falsedomyślnie:

Wymagaj, aby wtyczka jar zbudowała nowy plik JAR, nawet jeśli wydaje się, że żadna zawartość nie uległa zmianie. Domyślnie ta wtyczka sprawdza, czy plik jar wyjściowy istnieje, a dane wejściowe nie uległy zmianie. Jeśli te warunki są spełnione, wtyczka pomija tworzenie pliku jar.

Ale ładnie wypełni nam kontekst kompilacji i deploy:deployuszczęśliwi. Brak testów do pominięcia, brak profili do dodania. Dokładnie to, czego potrzebujesz: szybkość.


Dodatkowa uwaga: jeśli za pomocą build-helper-maven-plugin, buildnumber-maven-pluginlub dowolny inny podobny plugin do generowania metadanych później wykorzystywane przez maven-jar-plugin(np wpisy do pliku manifestu), to najprawdopodobniej masz egzekucje związane z validatefazą i nadal chcesz mieć je podczas jar:jaretapu budowy (i jeszcze utrzymać szybki wykonanie). W tym przypadku prawie nieszkodliwym narzutem jest wywołanie validate fazy w następujący sposób:

mvn validate jar:jar deploy:deploy

Jeszcze jedna dodatkowa uwaga: jeśli nie masz, jarale powiedzmy, warpakujesz, użyj war:warzamiast tego przed instalacją / wdrożeniem.

Gotcha, jak wskazano powyżej, sprawdź zachowanie w projektach wielomodułowych.


8
Wpadłem w dokładnie taki scenariusz. Fantastyczny opis - powinien znajdować się w FAQ wtyczki do wdrażania zamiast dość zwięzłego wyjaśnienia „nie możesz tego zrobić”.
markdsievers

Kto by pomyślał, że słoik może się jednak przydać;)
wearego

Zobacz moje rozwiązanie dla projektów z wieloma modułami: stackoverflow.com/a/57824874/318174
Adam Gent

to rozwiązanie działa dobrze w moim wielomodułowym projekcie @AdamGent
karakays

Doskonałe wyjaśnienie. Opisałem dokładnie mój scenariusz z moim serwerem Jenkins.
wimnat

14

Ta odpowiedź dotyczy bardzo starego pytania, aby pomóc innym w obliczu tego problemu.

Napotykam ten błąd podczas pracy nad Javaprojektem przy użyciu IntelliJ IDEAIDE.

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

to się nie powiodło, gdy wybieram install:installponiżej Plugins - install, jak wskazano czerwoną strzałką na poniższym obrazku.

Wybierz zły wybór

Po uruchomieniu wybranego installponiżej, Lifecyclejak pokazano powyżej, problem zniknął, a kompilacja kompilacji mavena zakończyła się pomyślnie.


6

Mam ten sam problem. Komunikat o błędzie nie jest kompletny. Ale w moim przypadku dodałem słoik generacji ze źródłami. Umieszczając ten kod w 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>

Tak więc w fazie wdrażania wykonuję cel source: jar, który tworzy jar ze źródłami. Wdrożenie kończy się SUKCESEM BUDOWY


2

musisz wyczyścić plik docelowy, taki jak w jar i inne W C: dysk folder w .m2 zobacz lokalizację, w której jest zainstalowany i usuń plik .jar, plik Snaphot i usuń pliki docelowe, a następnie wyczyść znalezioną aplikację, która zostanie uruchomiona


Cóż, częściowe rozwiązanie.
Jasper Lankhorst

2

Ten błąd pojawia się podczas korzystania z wtyczki maven-install-plugin w wersji 3.0.0-M1 (lub podobnej)

Jak już wspomniano powyżej, a także tutaj działa następująca wersja wtyczki:

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

1

Podczas gdy odpowiedź @ A_Di-Matteo działa dla nie multimodułów, mam rozwiązanie dla multimodułów.

Rozwiązaniem jest nadpisanie każdej konfiguracji wtyczki tak, aby wiązała się z fazą nonez wyjątkiem wtyczki jar / war / ear i oczywiście wtyczki do wdrażania. Nawet jeśli masz pojedynczy moduł, moje podstawowe testy pokazują, że jest to trochę szybsze (z powodów, których nie znam) pod względem wydajności.

Tak więc sztuczka polega na utworzeniu profilu, który wykonuje powyższe czynności, który jest aktywowany tylko wtedy, gdy chcesz wdrożyć.

Poniżej znajduje się przykład z jednego z moich projektów, który korzysta z wtyczki cieniowania i dlatego musiałem ponownie zastąpić wtyczkę jar, aby nie nadpisywać:

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

Teraz, jeśli uruchomię mvn deploy -Pdeploy, uruchomi tylko jar i wdroży wtyczki.

Aby dowiedzieć się, które wtyczki należy zastąpić, należy uruchomić wdrożenie i przejrzeć dziennik, aby sprawdzić, które wtyczki są uruchomione. Upewnij się, że idśledzisz konfigurację wtyczki, która jest połączona z nazwą wtyczki.


0

Miałem ten sam problem, ale początkowo wykonałem instalację mvn (nie instaluj: zainstaluj, jak wspomniano wcześniej).

Rozwiązanie ma obejmować:

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

Do sekcji zarządzania wtyczkami.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.