Maven: L'imballaggio per questo progetto non ha assegnato un file per il manufatto di compilazione

https://stackoverflow.com/questions/6308162

26-10-2019
|

Domanda

Sto usando Maven 3.0.3 su Mac 10.6.6. Ho un progetto JAR e quando faccio funzionare l'ordine "MVN nuova installazione: install", sto ottenendo l'errore,

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

Cosa significa e come posso risolvere il problema? Qui di seguito è il mio pom.xml. Fatemi sapere cosa altre informazioni sarebbe utile e Io modificare questo post. Grazie, - 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>

Soluzione

Non so se questa è la risposta o no, ma che potrebbe portare nella giusta direzione ...

Il comando install:install è in realtà un obiettivo su Maven-install-plugin . Questo è diverso rispetto alla fase install esperto di ciclo di vita.

Maven del ciclo di vita fasi sono passi in una build che alcuni plugin si possono legare a. Molti obiettivi diversi da diversi plugin possono eseguire quando si richiama una singola fase del ciclo di vita.

Che questo si riduce a è il comando ...

mvn clean install

è diverso da ...

mvn clean install:install

Il primo verrà eseguito tutti gli obiettivi in ??ogni ciclo che portano ad includere l'installazione (come compilazione, pacchetto, di test, etc.). Quest'ultimo nemmeno compilare o impacchettare il codice, sarà solo familiare che un obiettivo. Questo rende un pò senso, guardando l'eccezione; si parla di:

StarTeamCollisionUtil: La confezione per questo progetto non ha assegnato un file per il manufatto di build

Prova il primo e il tuo errore potrebbe solo andare via!

Altri suggerimenti

TL; DR Per risolvere questo problema, richiamare il confezionamento plugin di prima, ad esempio, per l'uso jar confezionamento maven-jar-plugin, come segue:

mvn jar:jar install:install

mvn jar:jar deploy:deploy

Se effettivamente necessari per distribuire.

Gotcha Questo approccio non funziona se si dispone di progetti multi-modulo con diversi imballaggi (orecchio / guerra / jar / zip) - saranno installati anche peggio, manufatti sbagliate / distribuito! In tali opzioni caso uso di reattori a costruire solo modulo dispiegabile (ad esempio la war).

Spiegazione

In alcuni casi si vuole realmente eseguire direttamente un install:install o deploy:deploy obiettivo (cioè dal maven-deploy-plugin, l'obiettivo deploy, non il deploy Maven fase ) e si finirebbe nel The packaging for this project did not assign a file to the build artifact fastidioso.

Un esempio classico è un lavoro CI (un lavoro Jenkins o di bambù, per esempio), dove in diverse fasi che si vuole eseguire / cura di diversi aspetti:

Un primo passo sarebbe una mvn clean install, l'esecuzione di test e copertura di test
Un secondo passo sarebbe un'analisi Sonarqube sulla base di un profilo di qualità, ad esempio mvn sonar:sonar più altre possibilità
Allora, e solo dopo i test di successo di esecuzione e qualità porta passato, si desidera distribuire al repository aziendale Maven i manufatti finali del progetto, ma non si vuole rieseguire mvn deploy, perché sarebbe ancora eseguire le fasi precedenti ( e compilazione, di test, etc.) e si desidera la build per essere efficace, ma ancora veloce .

Sì, si potrebbe accelerare questo ultimo passo, almeno per saltare i test (compilazione e l'esecuzione, tramite -Dmaven.test.skip=true ) o giocare con un particolare profilo (per saltare come molti plugin possibile), ma è molto più facile e chiaro per mvn deploy:deploy eseguire semplicemente poi.

Ma sarebbe riuscire con l'errore precedente, perché, come specificato anche dal plugin FAQ :

Durante il confezionamento fase tutti riuniti e collocato nel contesto. Con questo meccanismo Maven può garantire che il maven-install-plugin e maven-deploy-plugin stanno copiando / upload lo stesso insieme di file. Così, quando si esegue solo deploy:deploy, allora non ci sono file messi nel contesto e non c'è niente da distribuire.

In effetti, la deploy:deploy ha bisogno di informazioni di runtime collocato nel contesto di compilazione da fasi precedenti (o plugin precedenti / gol esecuzioni).

E 'riportato anche come un potenziale bug: MDEPLOY-158 : distribuire: distribuzione non funziona solo per distribuzione manufatto a Maven remoto repo

Ma poi respinto come non è un problema.

Il href="http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd" rel="noreferrer"> deployAtEnd configurazione delle opzioni della maven-deploy-plugin non aiuterà né in determinati scenari, perché abbiamo passaggi del processo intermedi per eseguire:

Sia che ogni progetto deve essere distribuito durante il proprio deploy-fase o alla fine della compilazione multimodulo. Se è impostata su true e la compilazione fallisce, nessuno dei progetti del reattore viene distribuito. (Sperimentale)

Quindi, come risolvere il problema?
È sufficiente eseguire il seguente in un tale simile terzo / ultimo passaggio:

mvn jar:jar deploy:deploy

Il maven-jar-plugin non sarà ricreare qualsiasi vaso come parte della vostra generazione, grazie alla sua forceCreation set opzione per false per impostazione predefinita:

Richiede il plugin vaso di costruire un nuovo JAR, anche se nessuno dei contenuti sembrano essere cambiate. Per impostazione predefinita, questo plugin cerca di vedere se il barattolo di uscita esiste e gli ingressi non sono cambiate. Se queste condizioni sono vere, il plugin salta creazione del vaso.

Ma sarà piacevolmente popolare il contesto costruire per noi e fare deploy:deploy felice. Nessun test per saltare, senza profili da aggiungere. Quello che vi serve: velocità

Nota aggiuntiva: se si utilizza il build-helper-maven-plugin, buildnumber-maven-plugin o qualsiasi altro plug-simile per generare meta-dati in seguito utilizzato dal maven-jar-plugin (ad esempio, le voci per il file Manifest), molto probabilmente hanno esecuzioni legate alla fase validate e si vuole ancora avere loro durante la fase di jar:jar build (e tuttavia mantenere una velocità di esecuzione). In questo caso l'overhead quasi innocuo è invocare la fase validate come segue:

mvn validate jar:jar deploy:deploy

Ancora un altro nota aggiuntiva:. Se non avete jar, ma, per esempio, l'imballaggio war, uso war:war prima di installare / distribuire invece

Gotcha come sottolineato in precedenza, il comportamento di arrivo in progetti multi-modulo.

Questa risposta è su un vecchia questione di aiutare gli altri di fronte a questo problema.

mi faccia questo errore fallito mentre io stavamo lavorando al mio Java progetto utilizzando 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

questo non è riuscito accade, quando scelgo install:install sotto Plugins - install, come evidenziato con la freccia rossa in seguito immagine.

Una volta che corro il install selezionata in Lifecycle come illustrato in precedenza, il problema andato, e il mio esperto di installare la generazione di compilazione con successo.

Ho lo stesso problema. Messaggio di errore per me non è completa. Ma nel mio caso, ho aggiunto vaso generazione con fonti. Inserendo questo codice 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>

Quindi, in fase di distribuzione eseguo fonte: obiettivo vaso che produce vaso con le fonti. E finisce Distribuisci con costruire il successo

è necessario cancellare il file di destinazione, come in vaso e altri In C: guidare la vostra cartella alla .m2 visualizzare la posizione in cui installare ed eliminare il file .jar, lima Snaphot e file di destinazione eliminare, quindi pulire l'applicazione avete trovato verrà eseguito

Ho avuto lo stesso problema, ma ho eseguito mvn install inizialmente (non install: install come è stato accennato in precedenza).

La soluzione è quella di includere:

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

In plug-sezione di gestione.

Questa mostra di errore quando si usa il Maven-install-plugin versione 3.0.0-M1 (o simili)

Come già mentioed sopra e anche qui il seguente plug-in funziona versione:

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

Mentre @ A_Di-Matteo risposta non lavoro per non multimodulo ho una soluzione per MultiModules.

La soluzione è quella di ignorare ogni configurazione del plugin in modo che si lega alla fase di none con l'eccezione della / guerra plug-jar / orecchio e, naturalmente, il plug-deploy. Anche se si dispone di un unico modulo miei test rudimentali dimostrano che questo sia un po 'più veloce (per ragioni che non so) le prestazioni saggio.

Così il trucco è quello di creare un profilo che fa quanto sopra che si attiva quando si desidera solo distribuire.

Di seguito è riportato un esempio di uno dei miei progetti che utilizza il plugin all'ombra e quindi ho dovuto re-ignorare il vaso plugin non sovrascrivere:

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

Ora, se corro mvn deploy -Pdeploy possa funzionare solo i plugin vaso e distribuire.

Come si può capire quali plugin è necessario sostituire è quello di eseguire implementare e sguardo al registro per vedere quali plugin sono in esecuzione. Assicurarsi di tenere traccia del id della configurazione del plugin che è parentesi dopo il nome del plugin.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow