test pom plugin example maven maven-3 pom.xml maven-jar-plugin maven-install-plugin

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