Maven: El empaque para este proyecto no asignó un archivo al artefacto de compilación

https://stackoverflow.com/questions/6308162

26-10-2019
|

Pregunta

Estoy usando Maven 3.0.3 en Mac 10.6.6. Tengo un proyecto JAR y cuando ejecuto el comando "MVN Clean Install: Install", recibo 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>

Solución

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 el plugin de instalación maven. Esto es diferente al install fase de ciclo de vida maven.

Fases de ciclo de vida maven son pasos en una construcción a la que ciertos complementos pueden unirse. Muchos objetivos diferentes de diferentes complementos pueden ejecutar cuando invoca una sola fase de ciclo de vida.

Lo que esto se reduce es el comando ...

mvn clean install

es diferente de...

mvn clean install:install

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

STARTEAMCOLLISIONUTIL: el empaque para este proyecto no asignó un archivo al artefacto de compilación

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

Otros consejos

Tl; Dr Para solucionar este problema, invocar el complemento de empaque antes, por ejemplo, para jar uso de empaquetado maven-jar-plugin , como lo sigue:

mvn jar:jar install:install

mvn jar:jar deploy:deploy

Si realmente necesitabas implementar.

Entendido Este enfoque no funcionará si tiene un proyecto de múltiples módulos con diferentes empacadores (oído/guerra/jar/zip), ¡peor aún, los artefactos incorrectos se instalarán/implementarán! En tal caso, use opciones de reactor para construir solo el módulo implementable (por ejemplo, el war).

Explicación

En algunos casos realmente quieres ejecutar directamente un install:install o deploy:deploy objetivo (es decir, del maven-deploy-plugin, la deploy meta, no la maven deploy fase) y terminarías 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 un mvn clean install, Realización de 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 Además de más opciones
Luego, y solo después de la ejecución exitosa de las pruebas y la puerta de calidad, desea implementar en su repositorio de empresas Maven los artefactos del proyecto final, sin embargo, no desea volver a ejecutar mvn deploy, porque volvería a ejecutar fases anteriores (y compilaría, probar, etc.) y desea que su compilación sea efectiva pero aún rápido.

Sí, podría acelerar este último paso al menos omitiendo 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 simplemente ejecutar mvn deploy:deploy después.

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

Durante la fase de empaquetado, todos se reunieron y se colocaron en contexto. Con este mecanismo, Maven puede garantizar que el maven-install-plugin y maven-deploy-plugin están copiando/cargando el mismo conjunto de archivos. Entonces, cuando solo ejecuta deploy:deploy, entonces no hay archivos puestos 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 anteriores de complementos/objetivos).

También ha informado como un posible error: MDEPLOY-158: implement: implement no funciona solo para implementar artefactos para el repositorio remoto de Maven

Pero luego rechazado como no un problema.

los deployAtEnd opción de configuración del maven-deploy-plugin No no ayudará a ninguno de los dos 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 construcción de multimódicos. Si se establece en true Y la compilación falla, ninguno de los proyectos de reactores se implementa. (experimental)

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

mvn jar:jar deploy:deploy

los maven-jar-plugin no recreará ningún frasco como parte de su construcción, gracias a su forceCreation opción establecida en false por defecto:

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

Pero se pondrá muy bien el contexto de construcción y hará deploy:deploy contento. No hay pruebas para omitir, no hay perfiles para agregar. Justo lo que necesitas: velocidad.

Nota adicional: si está utilizando el build-helper-maven-plugin, buildnumber-maven-plugin o cualquier otro complemento similar para generar metadatos más tarde utilizado por el maven-jar-plugin (por ejemplo, entradas para el archivo manifiesto), probablemente tenga ejecuciones vinculadas a la validate fase y todavía quieres tenerlos durante el jar:jar Paso de construcción (y sin embargo mantenga una ejecución rápida). En este caso, la sobrecarga casi inofensiva es invocar el validate fase Como lo siguiente:

mvn validate jar:jar deploy:deploy

Otra nota adicional más: si no ha jar Pero, digamos, war Embalaje, uso war:war Antes de instalar/implementar en su lugar.

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

Esta respuesta está en una pregunta muy antigua para ayudar a otros a enfrentar este problema.

Me enfrento a este error fallido mientras trabajaba en mi Java proyectar 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 falló que sucede cuando elijo install:install por debajo Plugins - install, como señaló con la flecha roja en la imagen de abajo.

Una vez que ejecuto el seleccionado install por debajo Lifecycle Como se ilustra anteriormente, el problema desapareció y mi compilación de instalación Maven se compila correctamente.

Tengo el mismo problema. El mensaje de error para mí no está completo. Pero en mi caso, he agregado Generation Jar con fuentes. Colocando 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 I de implementación, ejecute Fuente: JAR GOY que produce JAR con fuentes. Y el despliegue termina con el éxito de compilación

Debe borrar el archivo de destino, como en jar y otros en c: conducir su carpeta en .m2, consulte la ubicación donde instale y elimine el archivo .jar, el archivo snaphot y elimine los archivos de destino, luego limpie la aplicación que descubrió que se ejecutará

Tuve el mismo problema pero ejecuté instalación de MVN inicialmente (no Instalar: instalar 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 gestión de complementos.

Este error aparece cuando se usa Maven-Install-Plugin versión 3.0.0-M1 (o similar)

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

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

Mientras que la respuesta @a_di-matteo funciona para no multimódico, tengo una solución para multimódulos.

La solución es anular cada configuración del complemento para que se una a la fase de none con la excepción del complemento JAR/War/Ear y, por supuesto, del complemento de implementación. Incluso si tiene un solo módulo, mis pruebas rudimentarias muestran que esto es un rendimiento un poco más rápido (por razones que no sé).

Por lo tanto, el truco es hacer un perfil que haga lo anterior que se active cuando solo desea implementar.

A continuación se muestra un ejemplo de uno de mis proyectos que utiliza el complemento de sombra y, por lo tanto, tuve que reubicar el complemento JAR para no sobrescribir:

    <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 corro mvn deploy -Pdeploy Solo ejecutará los complementos JAR e implementará.

La forma en que puede 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 del id de la configuración del complemento, que es parens después del nombre del complemento.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow