pom - maven-assembly-plugin

Maven: El paquete para este proyecto no asignó un archivo al artefacto de construcción

Question

Estoy usando Maven 3.0.3 en Mac 10.6.6. Tengo un proyecto de 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 está 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>

Answer 1

Esta respuesta es una pregunta muy antigua para ayudar a otros a enfrentar este problema.

Me enfrento a este error fallido mientras estaba trabajando en mi proyecto Java usando 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

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

Una vez que ejecuto la install seleccionada en Lifecycle como se ilustra arriba, el problema desapareció, y mi desarrollador instaló la compilación satisfactoriamente.

Answer 2

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

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

Las fases del ciclo de vida de Maven son pasos en una compilación a la que ciertos complementos se pueden unir. Muchos objetivos diferentes de diferentes complementos se pueden ejecutar cuando se invoca una única fase del ciclo de vida.

Lo que se reduce a esto es el comando ...

mvn clean install

es diferente de...

mvn clean install:install

El primero ejecutará todos los objetivos en todos los ciclos previos e incluyendo la instalación (como compilación, paquete, prueba, etc.). Este último ni siquiera compilará ni empaquetará su código, solo ejecutará ese único objetivo. Esto tiene sentido, mirando la excepción; habla de:

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

¡Prueba lo primero y tu error podría desaparecer!

Answer 3

Tengo el mismo problema. El mensaje de error para mí no está completo. Pero en mi caso, he agregado generación jar con las 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 las fuentes. E implementar termina con BUILD SUCCESS

Answer 4

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

Answer 5

TL; DR Para solucionar este problema, invoque el complemento de empaquetado antes, por ejemplo, para el empaquetado de jar use maven-jar-plugin , como se maven-jar-plugin continuación:

mvn jar:jar install:install

O

mvn jar:jar deploy:deploy

Si realmente necesitabas implementar

Gotcha Este enfoque no funcionará si tienes un proyecto de varios módulos con diferentes embalajes (ear / war / jar / zip) - ¡aún peor, los artefactos incorrectos se instalarán / desplegarán! En tal caso, use las opciones del reactor para construir solo el módulo desplegable (por ejemplo, la war ).

Explicación

En algunos casos, realmente desea ejecutar directamente una install:install o deploy:deploy objetivo (es decir, desde el maven-deploy-plugin , el objetivo de deploy , no la phase deploy Maven) y terminaría en el molesto 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 una mvn clean install , realizar pruebas y cobertura de prueba
• Un segundo paso sería un análisis de Sonarqube basado en un perfil de calidad, por ejemplo, mvn sonar:sonar y otras opciones
• Luego, y solo después de la ejecución exitosa de las pruebas y la puerta de calidad aprobada, desea desplegar en su repositorio de Maven los artefactos finales del proyecto, pero no desea volver a ejecutar mvn deploy , ya que de nuevo ejecutaría las fases anteriores (y compilará , prueba, etc.) y quiere que su compilación sea efectiva pero a la vez rápida .

Sí, podría acelerar este último paso al menos omitir las pruebas (compilación y ejecución, a través de -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 para simplemente ejecutar mvn deploy:deploy then.

Pero fallaría con el error anterior, porque como también lo especifican las preguntas frecuentes del complemento :

Durante la fase de empaquetado, todos se reunieron y colocaron en contexto. Con este mecanismo, Maven puede garantizar que maven-install-plugin y maven-deploy-plugin copien / carguen el mismo conjunto de archivos. Por lo tanto, cuando solo ejecuta deploy:deploy , no hay archivos en el contexto y no hay nada que implementar.

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

También se ha informado de un error potencial: MDEPLOY-158 : implementar: la implementación no funciona solo para Implementar artefactos en el repositorio de Maven Remote

Pero luego rechazado como no es un problema.

La opción de configuración deployAtEnd de maven-deploy-plugin no ayudará 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 multímetro. Si se establece en true y la construcción falla, ninguno de los proyectos del reactor se implementa. (experimental)

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

mvn jar:jar deploy:deploy

El maven-jar-plugin no volverá a crear ningún jar como parte de su compilación, gracias a su opción forceCreation establecida en false por defecto:

Requerir que el plugin jar construya un nuevo JAR incluso si ninguno de los contenidos parece haber cambiado. Por defecto, este complemento busca ver si el jar de salida existe y las entradas no han cambiado. Si estas condiciones son verdaderas, el complemento omite la creación del contenedor.

Pero rellenará muy bien el contexto de compilación para nosotros y realizará la deploy:deploy feliz. Sin pruebas para saltar, sin perfiles para agregar. Justo lo que necesitas: velocidad.

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

mvn validate jar:jar deploy:deploy

Otra nota adicional: si no tiene jar pero, por ejemplo, embalaje de war , use war:war before install / deploy en su lugar.

Como se señaló anteriormente, compruebe el comportamiento en proyectos de varios módulos.