J'utilise Maven 3.0.3 sur Mac 10.6.6. J'ai un projet JAR et lorsque j'exécute la commande "mvn clean install: install", j'obtiens l'erreur,
[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'est-ce que cela signifie et comment puis-je y remédier? Voici mon pom.xml. Faites-moi savoir quelles autres informations seraient utiles et je modifierai ce message. Merci, - 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>
TL; DR Pour résoudre ce problème, appelez le plugin d'empaquetage avant, par exemple pour l'
jar
utilisation d'empaquetagemaven-jar-plugin
, comme suit:Ou
Si vous aviez réellement besoin de déployer.
Gotcha Cette approche ne fonctionnera pas si vous avez un projet multi-module avec différents packagings (ear / war / jar / zip) - pire encore, de mauvais artefacts seront installés / déployés! Dans ce cas, utilisez les options du réacteur pour construire uniquement le module déployable (par exemple le
war
).Explication
Dans certains cas, vous voulez en fait exécuter directement un objectif
install:install
oudeploy:deploy
(c'est-à-dire à partir demaven-deploy-plugin
l'deploy
objectif, pas de ladeploy
phase Maven ) et vous vous retrouverez dans l'ennuyeuxThe packaging for this project did not assign a file to the build artifact
.Un exemple classique est un travail CI (un travail Jenkins ou Bamboo, par exemple) où, à différentes étapes, vous voulez exécuter / vous soucier de différents aspects:
mvn clean install
effectuer des tests et une couverture de testmvn sonar:sonar
plus d'autres optionsmvn deploy
, car il exécuterait à nouveau les phases précédentes (et compiler, tester , etc.) et vous voulez que votre build soit efficace mais rapide .Oui, vous pouvez accélérer cette dernière étape au moins en sautant des tests (compilation et exécution, via
-Dmaven.test.skip=true
) ou jouer avec un profil particulier (pour sauter autant de plugins que possible), mais il est beaucoup plus facile et clair de simplement exécutermvn deploy:deploy
ensuite.Mais cela échouerait avec l'erreur ci-dessus, car comme spécifié également par la FAQ du plugin :
En effet, il
deploy:deploy
faut des informations d'exécution placées dans le contexte de construction par les phases précédentes (ou les précédentes exécutions de plugins / objectifs).Il a également signalé un bogue potentiel
MDEPLOY-158
:: deploy: deploy ne fonctionne pas uniquement pour le déploiement d'un artefact dans le référentiel Maven RemoteMais ensuite rejeté comme pas un problème.
L'
deployAtEnd
option de configuration demaven-deploy-plugin
n'aidera pas non plus dans certains scénarios car nous avons des étapes de travail intermédiaires à exécuter:Alors, comment y remédier?
Exécutez simplement ce qui suit dans une troisième / dernière étape similaire:
Le
maven-jar-plugin
ne recréera aucun pot dans le cadre de votre build, grâce à sonforceCreation
option définiefalse
par défaut:Mais cela remplira bien le contexte de construction pour nous et nous rendra
deploy:deploy
heureux. Aucun test à sauter, aucun profil à ajouter. Juste ce dont vous avez besoin: la vitesse.Remarque supplémentaire: si vous utilisez le
build-helper-maven-plugin
,buildnumber-maven-plugin
ou tout autre plugin similaire pour générer des méta-données ultérieurement utilisées par lemaven-jar-plugin
(par exemple des entrées pour le fichier Manifest), vous avez très probablement des exécutions liées à lavalidate
phase et vous souhaitez toujours les avoir pendant l'jar:jar
étape de construction (tout en gardant une exécution rapide). Dans ce cas, la surcharge presque inoffensive consiste à invoquer lavalidate
phase comme suit:Encore une autre note supplémentaire: si vous n'avez pas
jar
mais, disons, l'war
empaquetage, utilisezwar:war
plutôt avant l'installation / le déploiement.Gotcha comme indiqué ci-dessus, vérifiez le comportement dans les projets multi-modules.
la source
Cette réponse est sur une question très ancienne pour aider les autres confrontés à ce problème.
Je fais face à cette erreur échouée pendant que je travaillais sur mon
Java
projet en utilisant l'IntelliJ IDEA
IDE.cet échec se produit, lorsque je choisis ci-
install:install
dessousPlugins - install
, comme indiqué par une flèche rouge dans l'image ci-dessous.Une fois que j'ai exécuté le
install
sous sélectionnéLifecycle
comme illustré ci-dessus, le problème a disparu et ma compilation maven install compile avec succès.la source
J'ai le même problème. Le message d'erreur pour moi n'est pas complet. Mais dans mon cas, j'ai ajouté le pot de génération avec les sources. En plaçant ce code dans pom.xml:
Donc, dans la phase de déploiement, j'exécute source: jar goal qui produit le jar avec les sources. Et le déploiement se termine par BUILD SUCCESS
la source
vous devez effacer le fichier cible tel que dans jar et autres En C: conduisez votre dossier à .m2 voir l'emplacement où il installe et supprimez le fichier .jar, le fichier Snaphot et supprimez les fichiers cible puis nettoyez l'application que vous avez trouvée qu'il sera exécuté
la source
Cette erreur apparaît lors de l'utilisation de la version 3.0.0-M1 de maven-install-plugin (ou similaire)
Comme déjà mentionné ci-dessus et également ici, la version de plug-in suivante fonctionne:
la source
Bien que la réponse @ A_Di-Matteo fonctionne pour les non multimodules, j'ai une solution pour les multimodules.
La solution est de surcharger chaque configuration de plugin pour qu'elle se lie à la phase de
none
à l'exception du plugin jar / war / ear et bien sûr du plugin deploy. Même si vous avez un seul module, mes tests rudimentaires montrent que c'est un peu plus rapide (pour des raisons que je ne connais pas) en termes de performances.Ainsi, l'astuce consiste à créer un profil qui fait ce qui précède qui est activé lorsque vous ne souhaitez déployer.
Vous trouverez ci-dessous un exemple d'un de mes projets qui utilise le plugin shadow et j'ai donc dû redéfinir le plugin jar pour ne pas écraser:
Maintenant, si je l'exécute,
mvn deploy -Pdeploy
il n'exécutera que le fichier jar et déploiera des plugins.La façon dont vous pouvez déterminer les plugins à remplacer consiste à exécuter le déploiement et à consulter le journal pour voir quels plugins sont en cours d'exécution. Assurez-vous de garder une trace de la
id
configuration du plugin qui est parens après le nom du plugin.la source
J'ai eu le même problème mais j'ai exécuté mvn install initialement (pas installer: installer comme cela a été mentionné plus tôt).
La solution consiste à inclure:
Dans la section de gestion des plugins.
la source