Maven: L’emballage de ce projet n’a pas affecté de fichier à l’artefact de construction

J’utilise Maven 3.0.3 sur Mac 10.6.6. J’ai un projet JAR et quand je lance la commande “mvn clean install: install”, je reçois 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 le réparer? Voici mon pom.xml. Faites-moi savoir quelles autres informations seraient utiles et je vais modifier ce post. Merci, – Dave

  4.0.0 com.myco.starteam.util StarTeamCollisionUtil jar StarTeam Collision Util  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.  1.0-SNAPSHOT http://cm-build.myco.com:8080/hudson/view/Tools/job/StarTeamCollisionUtil - TRUNK/  UTF-8    myco-sonatype-nexus-snapshots MyCo Sonatype-Nexus Snapshots http://sonatype.myco.com/nexus/content/repositories/snapshots/     starteam starteam 1.1.0 jar system ${basedir}/lib/starteam110.jar   junit junit 4.8.2   org.apache.ant ant 1.8.1   javax.mail mail 1.4.1 jar comstack      org.apache.maven.plugins maven-surefire-plugin 2.8.1   org.apache.maven.plugins maven-site-plugin 3.0-beta-3    org.apache.maven.plugins maven-surefire-report-plugin 2.5   org.apache.maven.plugins maven-javadoc-plugin 2.7  true    org.apache.maven.plugins maven-jxr-plugin 2.2   org.codehaus.mojo versions-maven-plugin 1.2   org.apache.maven.plugins maven-project-info-reports-plugin 2.3.1    index dependencies dependency-management cim issue-tracking license scm            sonatype-nexus http://sonatype.myco.com/nexus/content/repositories/snapshots/    https://starteam.cmass.myco.com/BorlandStarTeam/BorlandStarTeam.jsp   StarTeam https://starteam.cmass.myco.com/BorlandStarTeam/BorlandStarTeam.jsp   Hudson http://cm-build.myco.com:8080/hudson/   

    Je ne sais pas si c’est la réponse ou non mais ça pourrait vous conduire dans la bonne direction …

    La commande install:install est en fait un objective sur le plugin maven-install . Ceci est différent de la phase du cycle de vie install maven.

    Les phases du cycle de vie de Maven sont des étapes d’une construction à laquelle certains plug-ins peuvent se lier. De nombreux objectives différents provenant de différents plug-ins peuvent être exécutés lorsque vous appelez une phase de cycle de vie unique.

    Qu’est-ce que cela se résume à la commande …

     mvn clean install 

    est différent de…

     mvn clean install:install 

    Le premier exécutera tous les objectives à chaque cycle menant à l’installation, y compris la compilation, le package, le test, etc. Ce dernier ne comstackra ou ne comstackra même pas votre code, il exécutera simplement cet objective. Cela a du sens, en regardant l’exception; ça parle de:

    StarTeamCollisionUtil: L’emballage de ce projet n’a pas affecté de fichier à l’artefact de génération

    Essayez le premier et votre erreur pourrait disparaître!

    TL; DR Pour résoudre ce problème, appelez le plug-in de packaging avant, par exemple pour le jar utilisez maven-jar-plugin , comme suit:

     mvn jar:jar install:install 

    Ou

     mvn jar:jar deploy:deploy 

    Si vous aviez réellement besoin de déployer

    Gotcha Cette approche ne fonctionnera pas si vous avez un projet multi-module avec des packagings différents (ear / war / jar / zip) – pire encore, de faux artefacts seront installés / déployés! Dans ce cas, utilisez les options du réacteur pour ne construire que le module déployable (par exemple la war ).


    Explication

    Dans certains cas, vous voulez réellement exécuter directement une install:install objective install:install ou deploy:deploy (c’est-à-dire depuis le maven-deploy-plugin , l’objective de deploy , pas la phase de deploy Maven) et vous vous retrouverez The 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 souhaitez exécuter / prendre en compte différents aspects:

    • Une première étape consisterait à effectuer une mvn clean install , à effectuer des tests et à tester la couverture.
    • Une deuxième étape serait une parsing Sonarqube basée sur un profil de qualité, par mvn sonar:sonar plus d’autres options
    • Ensuite, et seulement après l’exécution réussie des tests et la qualité, vous souhaitez déployer dans votre référentiel d’entreprise Maven les artefacts du projet final, mais vous ne souhaitez pas réexécuter mvn deploy , car il exécute à nouveau les phases précédentes (et comstack , test, etc.) et vous voulez que votre build soit efficace mais rapide .

    Oui, vous pourriez 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 c’est beaucoup plus facile et clair pour exécuter simplement mvn deploy:deploy puis.

    Mais il échouerait avec l’erreur ci-dessus, car comme le spécifie également la FAQ du plugin :

    Au cours de la phase de conditionnement, tout est rassemblé et placé en contexte. Avec ce mécanisme, Maven peut s’assurer que les maven-install-plugin et maven-deploy-plugin copient / téléchargent le même ensemble de fichiers. Ainsi, lorsque vous n’exécutez que deploy:deploy , aucun fichier n’est placé dans le contexte et il n’y a rien à déployer.

    En effet, deploy:deploy nécessite des informations d’exécution placées dans le contexte de construction par les phases précédentes (ou les exécutions précédentes de plug-ins / objectives).

    Il a également signalé un bogue potentiel: MDEPLOY-158 : deploy: deploy ne fonctionne pas uniquement Déploiement d’artefact sur Maven Remote repo

    Mais alors rejeté comme pas un problème.

    L’option de configuration deployAtEnd du maven-deploy-plugin ne vous aidera pas dans certains scénarios, car nous avons des étapes de travail intermédiaires à exécuter:

    Si chaque projet doit être déployé pendant sa propre phase de déploiement ou à la fin de la construction du multimodule. Si défini sur true et que la construction échoue, aucun des projets de réacteur n’est déployé. (expérimental)

    Alors, comment le réparer?
    Exécutez simplement ce qui suit dans une troisième et dernière étape similaire:

     mvn jar:jar deploy:deploy 

    Le maven-jar-plugin ne recrée aucun jar dans votre build, grâce à son option forceCreation définie sur false par défaut:

    Exiger que le plug-in jar crée un nouveau fichier JAR même si aucun contenu ne semble avoir changé. Par défaut, ce plugin vérifie si le fichier de sortie existe et que les entrées n’ont pas changé. Si ces conditions sont vraies, le plug-in ignore la création du fichier jar.

    Mais cela va remplir le contexte de construction pour nous et faire en sorte que deploy:deploy heureux. Aucun test à ignorer, aucun profil à append. Juste ce dont vous avez besoin: la vitesse.


    Note supplémentaire: si vous utilisez le build-helper-maven-plugin buildnumber-maven-plugin , le build-helper-maven-plugin buildnumber-maven-plugin ou tout autre buildnumber-maven-plugin similaire pour générer ultérieurement des métadonnées utilisées par le maven-jar-plugin (par exemple, les entrées du fichier manifeste), vous avez probablement des exécutions liées à la phase de validate et vous voulez toujours les avoir lors de l’étape de compilation jar:jar (tout en gardant une exécution rapide). Dans ce cas, la surcharge presque inoffensive consiste à appeler la phase de validate comme suit:

     mvn validate jar:jar deploy:deploy 

    Encore une autre remarque: si vous n’avez pas de jar mais, disons, un emballage de war , utilisez plutôt war:war avant d’installer / déployer.

    Gotcha comme indiqué ci-dessus, vérifiez le comportement dans les projets multi-modules.

    J’ai le même problème. Le message d’erreur pour moi n’est pas complet. Mais dans mon cas, j’ai ajouté un générateur de génération avec des sources. En plaçant ce code dans pom.xml:

         maven-source-plugin 2.1.2   deploy  jar        

    Donc, en phase de déploiement, j’exécute le but source: jar qui produit des jar avec les sources. Et déployer se termine avec BUILD SUCCESS

    vous devez effacer le fichier cible comme dans jar et autres. En C: conduisez votre dossier à .m2 voir l’emplacement où il installe et supprime le fichier .jar, le fichier Snaphot et supprime les fichiers cibles puis nettoie l’application que vous avez trouvée.

    Cette réponse est sur une très vieille question pour aider les autres personnes confrontées à ce problème.

    Je suis confronté à cette erreur lors de mon projet Java avec 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 

    cet échec se produit, quand je choisis d’ install:install sous Plugins - install , comme indiqué avec la flèche rouge dans l’image ci-dessous.

    Choisir une mauvaise sélection

    Une fois que je lance l’ install sélectionnée sous Lifecycle comme illustré ci-dessus, le problème a disparu et ma compilation maven install comstack correctement.