Maven: o pacote para este projeto não atribuiu um arquivo ao artefato de construção


113

Estou usando o Maven 3.0.3 no Mac 10.6.6. Tenho um projeto JAR e, quando executo o comando "mvn clean install: install", recebo o erro,

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

O que isso significa e como posso corrigir isso? Abaixo está meu pom.xml. Deixe-me saber quais outras informações seriam úteis e eu editarei esta postagem. Obrigado, - 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>

Respostas:


168

Não sei se essa é a resposta ou não, mas pode levar você na direção certa ...

O comando install:installé na verdade um objetivo no maven-install-plugin . Isso é diferente da installfase do ciclo de vida do maven.

As fases do ciclo de vida do Maven são etapas em uma construção às quais certos plug-ins podem se vincular. Muitos objetivos diferentes de plug-ins diferentes podem ser executados quando você invoca uma única fase do ciclo de vida.

O que isso significa é o comando ...

mvn clean install

é diferente de...

mvn clean install:install

O primeiro executará todos os objetivos em cada ciclo que leva até e incluindo a instalação (como compilar, pacote, teste, etc.). Este último nem mesmo irá compilar ou empacotar seu código, ele apenas executará aquele objetivo. Isso meio que faz sentido, olhando para a exceção; Isso fala sobre:

StarTeamCollisionUtil: o pacote para este projeto não atribuiu um arquivo ao artefato de construção

Experimente o primeiro e seu erro pode simplesmente desaparecer!


Estou executando o Bamboo, mas não vejo nada do mvn install: install any where in config
Pra_A

96

TL; DR Para corrigir esse problema, invoque o plug-in de empacotamento antes, por exemplo, para jaruso de empacotamento maven-jar-plugin, como segue:

mvn jar:jar install:install

Ou

mvn jar:jar deploy:deploy 

Se você realmente precisava implantar.

Gotcha Esta abordagem não funcionará se você tiver um projeto de vários módulos com embalagens diferentes (ear / war / jar / zip) - pior ainda, artefatos errados serão instalados / implantados! Nesse caso, use as opções do reator para construir apenas o módulo implantável (por exemplo, o war).


Explicação

Em alguns casos, você realmente deseja executar diretamente um objetivo install:installou deploy:deploy(ou seja, a partir maven-deploy-plugindo deployobjetivo, não da deploy fase Maven ) e acabaria na fase chata The packaging for this project did not assign a file to the build artifact.

Um exemplo clássico é um trabalho de CI (um trabalho Jenkins ou Bamboo, por exemplo) em que em diferentes etapas você deseja executar / se preocupar com diferentes aspectos:

  • Uma primeira etapa seria mvn clean installrealizar testes e cobertura de teste
  • Uma segunda etapa seria uma análise Sonarqube com base em um perfil de qualidade, por exemplo, mvn sonar:sonarmais opções
  • Então, e somente após a execução bem-sucedida dos testes e a passagem de qualidade passar, você deseja implantar em seu repositório corporativo Maven os artefatos finais do projeto, mas não quer executá- mvn deploylos novamente, porque ele executaria novamente as fases anteriores (e compilar, testar etc.) e você deseja que sua construção seja eficaz, mas ainda assim rápida .

Sim, você poderia acelerar esta última etapa, pelo menos, pulando testes (compilação e execução, via -Dmaven.test.skip=true) ou brincar com um perfil específico (para pular o máximo de plug-ins possível), mas é muito mais fácil e claro simplesmente executá mvn deploy:deploy-lo.

Mas falharia com o erro acima, porque também especificado no FAQ do plugin :

Durante a fase de embalagem, todos são reunidos e colocados no contexto. Com esse mecanismo, o Maven pode garantir que o maven-install-plugine maven-deploy-pluginesteja copiando / carregando o mesmo conjunto de arquivos. Portanto, quando você apenas executa deploy:deploy, não há arquivos colocados no contexto e não há nada para implantar.

Na verdade, ele deploy:deployprecisa de algumas informações de tempo de execução colocadas no contexto de construção por fases anteriores (ou plug-ins / execuções de objetivos anteriores).

Também foi relatado como um bug em potencial MDEPLOY-158:: deploy: deploy não funciona apenas para o artefato de implantação no repositório remoto Maven

Mas então rejeitado como um problema.

A deployAtEndopção de configuração do maven-deploy-pluginnão vai ajudar em certos cenários, porque temos etapas de trabalho intermediárias para executar:

Se cada projeto deve ser implantado durante sua própria fase de implantação ou no final da construção do multimódulo. Se definido como truee a construção falhar, nenhum dos projetos de reator será implantado. (experimental)

Então, como consertar?
Basta executar o seguinte em uma terceira / última etapa semelhante:

mvn jar:jar deploy:deploy

O maven-jar-pluginnão irá recriar nenhum jar como parte de sua construção, graças à sua forceCreationopção definida como falsepadrão:

Exigir que o plug-in jar crie um novo JAR, mesmo que nenhum conteúdo pareça ter sido alterado. Por padrão, este plugin verifica se o jar de saída existe e se as entradas não foram alteradas. Se essas condições forem verdadeiras, o plug-in ignora a criação do jar.

Mas vai preencher o contexto de construção para nós e nos deixar deploy:deployfelizes. Sem testes para pular, sem perfis para adicionar. Exatamente o que você precisa: velocidade.


Nota adicional: se você estiver usando o build-helper-maven-plugin, buildnumber-maven-pluginou qualquer outro plugin semelhante para gerar metadados posteriormente usados ​​pelo maven-jar-plugin(por exemplo, entradas para o arquivo Manifest), você provavelmente tem execuções vinculadas à validatefase e ainda deseja tê-las durante a jar:jaretapa de construção (e ainda manter uma execução rápida). Neste caso, a sobrecarga quase inofensiva é invocar a validate fase da seguinte forma:

mvn validate jar:jar deploy:deploy

Ainda outra nota adicional: se você não tiver jar, mas, digamos, warempacotando, use war:warantes de instalar / implantar.

Gotcha como apontado acima, verifique o comportamento em projetos de vários módulos.


8
Encontrei exatamente este cenário. Escrita fantástica - deve estar no FAQ de implantação do plugin, em vez da explicação concisa "você não pode fazer isso".
markdsievers de

Quem teria pensado que jar jar pode ser útil afinal;)
wearego

Veja minha solução para projetos de vários módulos: stackoverflow.com/a/57824874/318174
Adam Gent

esta solução funciona bem para meu projeto de vários módulos @AdamGent
karakays

Excelente explicação. Descreveu exatamente meu cenário com meu servidor Jenkins.
wimnat

14

Esta resposta é para uma pergunta muito antiga para ajudar outras pessoas a enfrentar esse problema.

Enfrentei esse erro de falha enquanto estava trabalhando em meu Javaprojeto usando 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

esta falha acontece, quando eu escolho install:installabaixo Plugins - install, conforme apontado com a seta vermelha na imagem abaixo.

Escolha a seleção errada

Uma vez que eu executar o selecionado installsob Lifecyclecomo ilustrado acima, a questão foi, e meus maven instalar construção de compilação com sucesso.


6

Eu tenho o mesmo problema. A mensagem de erro para mim não está completa. Mas, no meu caso, adicionei o jarro de geração com fontes. Colocando este código em 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>

Então, na fase de implantação, eu executo source: jar goal que produz jar com sources. E a implantação termina com BUILD SUCCESS


2

você deve limpar o arquivo de destino, como em jar e outros. Em C: dirija sua pasta em .m2 veja o local onde ele instalou e exclua o arquivo .jar, o arquivo Snaphot e exclua os arquivos de destino, em seguida, limpe o aplicativo que você encontrou para ser executado


Bem, uma solução parcial.
Jasper Lankhorst

2

Este erro aparece ao usar o maven-install-plugin versão 3.0.0-M1 (ou semelhante)

Conforme já mencionado acima e também aqui funciona a seguinte versão do plug-in:

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

1

Embora a resposta @A_Di-Matteo funcione para não multimódulos, tenho uma solução para multimódulos.

A solução é sobrescrever a configuração de cada plugin para que se vincule à fase de, nonecom exceção do plugin jar / war / ear e, claro, do plugin de implantação. Mesmo se você tiver um único módulo, meus testes rudimentares mostram que ele é um pouco mais rápido (por razões que não sei) em termos de desempenho.

Assim, o truque é fazer um perfil que faça o acima exposto que seja ativado quando você apenas deseja implantar.

Abaixo está um exemplo de um dos meus projetos que usa o plug-in sombra e, portanto, tive que substituir o plug-in jar para não sobrescrever:

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

Agora, se eu executar, mvn deploy -Pdeployele apenas executará o jar e implantará os plug-ins.

Como você pode descobrir quais plug-ins você precisa substituir é executar o deploy e olhar o log para ver quais plug-ins estão em execução. Certifique-se de acompanhar a idconfiguração do plug-in, que é parênteses após o nome do plug-in.


0

Eu tive o mesmo problema, mas executei inicialmente mvn install (não instale: instale como mencionado anteriormente).

A solução é incluir:

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

Na seção de gerenciamento de plug-ins.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.