Maven: el paquete de este proyecto no asignó un archivo al artefacto de compilación

Estoy usando Maven 3.0.3 en Mac 10.6.6. Tengo un proyecto JAR y cuando ejecuto el comando "mvn clean install: install", aparece el error,

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

¿Qué significa esto y cómo puedo solucionarlo? A continuación se muestra mi pom.xml. Déjame saber qué otra información sería útil y editaré esta publicación. Gracias, - 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>

No sé si esta es la respuesta o no, pero podría llevarte en la dirección correcta ...

El comando install:installes en realidad un objetivo en maven-install-plugin . Esto es diferente a la installfase del ciclo de vida de maven.

Las fases del ciclo de vida de Maven son pasos en una compilación a los que se pueden vincular ciertos complementos. Se pueden ejecutar muchos objetivos diferentes de diferentes complementos cuando se invoca una sola fase del ciclo de vida.

Esto se reduce al comando ...

mvn clean install

es diferente de...

mvn clean install:install

El primero ejecutará todos los objetivos en cada ciclo previo a la instalación e incluida (como compilación, paquete, prueba, etc.). Este último ni siquiera compilará o empaquetará su código, solo ejecutará ese objetivo. Esto tiene un poco de sentido, mirando la excepción; habla de:

StarTeamCollisionUtil: el paquete de este proyecto no asignó un archivo al artefacto de compilación

¡Pruebe el primero y su error podría desaparecer!

TL; DR Para solucionar este problema, invoque el complemento de empaquetado antes, por ejemplo, para jarel uso de empaquetado maven-jar-plugin, de la siguiente manera:

mvn jar:jar install:install

O

mvn jar:jar deploy:deploy 

Si realmente necesita implementar.

Gotcha Este enfoque no funcionará si tiene un proyecto de varios módulos con diferentes empaques (ear / war / jar / zip); lo que es peor, ¡se instalarán / implementarán artefactos incorrectos! En tal caso, utilice las opciones de reactor para construir únicamente el módulo desplegable (por ejemplo, el war).

Explicación

En algunos casos, realmente desea ejecutar directamente un objetivo install:installo deploy:deploy(es decir, desde maven-deploy-pluginel deployobjetivo, no la deploy fase de Maven ) y terminaría en la fase molesta The packaging for this project did not assign a file to the build artifact.

Un ejemplo clásico es un trabajo de CI (un trabajo de Jenkins o Bamboo, por ejemplo) donde en diferentes pasos desea ejecutar / preocuparse por diferentes aspectos:

• Un primer paso sería mvn clean installrealizar pruebas y realizar pruebas de cobertura.
• Un segundo paso sería un análisis de Sonarqube basado en un perfil de calidad, por ejemplo, mvn sonar:sonarmás opciones adicionales
• Luego, y solo después de que se haya superado la ejecución exitosa de las pruebas y la puerta de calidad, desea implementar en su repositorio empresarial de Maven los artefactos del proyecto final, pero no desea volver a ejecutar mvn deploy, porque volvería a ejecutar las fases anteriores (y compilar, probar , etc.) y desea que su construcción sea efectiva pero rápida .

Sí, podría acelerar este último paso al menos omitiendo las pruebas (compilación y ejecución, vía -Dmaven.test.skip=true) o jugar con un perfil en particular (para omitir tantos complementos como sea posible), pero es mucho más fácil y claro simplemente ejecutarlo mvn deploy:deploy.

Pero fallaría con el error anterior, porque como también se especifica en las Preguntas frecuentes del complemento :

Durante la fase de empaque, todo se reunió y se puso en contexto. Con este mecanismo, Maven puede asegurarse de que maven-install-pluginy maven-deploy-pluginestén copiando / cargando el mismo conjunto de archivos. Entonces, cuando solo ejecuta deploy:deploy, entonces no hay archivos en el contexto y no hay nada que implementar.

De hecho, deploy:deploynecesita cierta información de tiempo de ejecución colocada en el contexto de compilación por fases anteriores (o ejecuciones de complementos / objetivos anteriores).

También se ha informado como un error potencial MDEPLOY-158:: deploy: deploy no funciona solo para Implementar artefactos en el repositorio remoto de Maven

Pero luego rechazado como no un problema.

La deployAtEndopción de configuración del maven-deploy-pluginno ayudará tampoco en ciertos escenarios porque tenemos pasos de trabajo intermedios para ejecutar:

Si cada proyecto debe implementarse durante su propia fase de implementación o al final de la compilación de varios módulos. Si se establece en truey la compilación falla, no se implementa ninguno de los proyectos del reactor. (experimental)

Entonces, ¿cómo solucionarlo?
Simplemente ejecute lo siguiente en un tercer / último paso similar:

mvn jar:jar deploy:deploy

El maven-jar-pluginno va a volver a crear cualquier frasco como parte de su construcción, gracias a su forceCreationconjunto de opciones a falsepor defecto:

Requiere que el complemento jar cree un nuevo JAR incluso si ninguno de los contenidos parece haber cambiado. De forma predeterminada, este complemento busca ver si el jar de salida existe y las entradas no han cambiado. Si se cumplen estas condiciones, el complemento omite la creación del archivo jar.

Pero poblará muy bien el contexto de compilación para nosotros y nos hará deploy:deployfelices. No hay pruebas que omitir, no hay perfiles que agregar. Justo lo que necesitas: velocidad.

Nota adicional: si está utilizando el build-helper-maven-plugin, buildnumber-maven-plugino cualquier otro complemento similar para generar metadatos más adelante utilizados por el maven-jar-plugin(por ejemplo, entradas para el archivo de manifiesto), lo más probable es que tenga ejecuciones vinculadas a la validatefase y aún desea tenerlas durante el jar:jarpaso de compilación (y aún así mantener una ejecución rápida). En este caso, la sobrecarga casi inofensiva es invocar la validate fase de la siguiente manera:

mvn validate jar:jar deploy:deploy

Sin embargo, otra nota adicional: si no lo ha hecho jarpero, digamos, warempaquetado, úselo war:warantes de instalar / implementar en su lugar.

Entendido como se señaló anteriormente, verifique el comportamiento en proyectos de múltiples módulos.

Esta respuesta es sobre una pregunta muy antigua para ayudar a otros que enfrentan este problema.

Enfrento este error fallido mientras trabajaba en mi Javaproyecto 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

esto falla, cuando elijo install:installdebajo Plugins - install, como se señala con la flecha roja en la imagen de abajo.

Una vez seleccionado el corro installbajo Lifecyclecomo se ilustra arriba, el problema ha ido, y mis experto instale versión de compilación con éxito.

Tengo el mismo problema. El mensaje de error para mí no está completo. Pero en mi caso, agregué un jar de generación con fuentes. Al colocar este código en 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>

Entonces, en la fase de implementación ejecuto source: jar goal que produce jar con sources. Y la implementación termina con BUILD SUCCESS

debe borrar el archivo de destino, como en jar y otros En C: maneje su carpeta en .m2 vea la ubicación donde se instala y elimine el archivo .jar, el archivo Snaphot y elimine los archivos de destino, luego limpie la aplicación que encontró que se ejecutará

Este error aparece cuando se usa la versión 3.0.0-M1 de maven-install-plugin (o similar)

Como ya se mencionó anteriormente y también aquí, funciona la siguiente versión del complemento:

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

Si bien la respuesta de @ A_Di-Matteo funciona para módulos no múltiples, tengo una solución para módulos múltiples.

La solución es anular cada configuración de complemento para que se una a la fase de nonecon la excepción del complemento jar / war / ear y, por supuesto, el complemento de implementación. Incluso si tiene un solo módulo, mis pruebas rudimentarias muestran que esto es un poco más rápido (por razones que no sé) en cuanto al rendimiento.

Así el truco está en hacer un perfil que haga lo anterior que se active cuando solo quieras desplegar.

A continuación se muestra un ejemplo de uno de mis proyectos que usa el complemento de sombra y, por lo tanto, tuve que volver a anular el complemento de jar para no sobrescribirlo:

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

Ahora, si lo ejecuto mvn deploy -Pdeploy, solo ejecutará el jar e implementará complementos.

La forma de averiguar qué complementos necesita anular es ejecutar la implementación y mirar el registro para ver qué complementos se están ejecutando. Asegúrese de realizar un seguimiento de la idconfiguración del complemento, que se encuentra detrás del nombre del complemento.

Tuve el mismo problema pero ejecuté mvn install inicialmente (no install: install como se mencionó anteriormente).

La solución es incluir:

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

En la sección de administración de complementos.