pom - maven-assembly-plugin
Maven: El paquete para este proyecto no asignó un archivo al artefacto de construcción (5)
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.
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>
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!
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
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á
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
ymaven-deploy-plugin
copien / carguen el mismo conjunto de archivos. Por lo tanto, cuando solo ejecutadeploy: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.