J'ai un bocal tiers qui est nécessaire à notre projet. Il n'est pas disponible sur le référentiel Central Maven, donc j'ai utilisé le plugin Maven-Installe pour installer le pot localement pendant une construction. J'ai attaché l'objectif "Fichier d'installation" à la phase "Validate", et cela fonctionne principalement. L'extrait de fichier pom.xml est ci-dessous: Cependant, il y a une prise. La plupart de nos développeurs et notre installation Jenkins exécutent "MVN Clean Installe". La phase "Validate" ne fait pas partie du cycle de vie "propre" et ne nécessite inexplicablement que toutes les dépendances sont présentes à exécuter. Donc, la première fois que quelqu'un dirige cette construction, cela ne fonctionne pas. Si je devais exécuter simplement "MVN Install", le pot est installé pendant "valider" et Je peux exécuter "MVN Clean Install" dans les constructions ultérieures. Cependant, notre serveur de construction n'a pas cette flexibilité. J'ai envisagé ce qui suit: Idéalement, j'aimerais aimer une autre option. Est-il possible de courir propre sans dépendances? Ou pour exécuter un plugin deux fois sans avoir à copier complètement l'exécution? Merci!
4 Réponses :
On dirait que vous utilisez Nexus. Il pourrait être plus facile de déployer l'artefact auprès du Repo Nexus, au lieu de devoir le maintenir avec ce projet.
C'est une bonne pensée, mais nous sommes dans une société internationale avec des équipes de développement fragmentées. L'obtenir sur le Master Nexus est un processus long. = (
Que diriez-vous d'utiliser un référentiel de fichiers local? Vous pouvez emballer le fichier dans un répertoire pair / enfant avec votre module, puis ajouter ce répertoire sous forme de fichier: repo dans votre pom.xml. Vous pouvez configurer vos paramètres.xml pour utiliser votre repo Nexus comme miroir mais permettez toujours aux repos de fichiers locaux.
Massfords: Modification des paramètres.xml est un non-démarreur, qui affecterait tout le monde qui utilise la construction. Je ferais mieux d'obtenir l'artefact sur le Maître Nexus. Je vais accepter celui-ci comme la réponse, car même si cela ne résout pas ma situation particulière, elle devrait pour la plupart des gens.
Au cas où d'autres sont curieux, ma suggestion sur les paramètres.xml était de modifier votre réglage de miroir pour être
Ceci n'est pas testé, mais pouvez-vous ignorer l'erreur de la configuration du plugin propre? Comme dans: (ceci est issu de
Malheureusement, non, l'écheconError ne contourne pas d'être incapable de résoudre les dépendances.
Voici une autre possibilité.
Configurez Maven pour ignorer la phase propre et être propre pendant l'initialisation. N'a pas essayé cela cependant.
L'inconvénient de ceci est Maven nettoiera toujours les dossiers de sortie.
J'ai rencontré un problème connexe et j'ai trouvé cette question lorsque Googling pour une solution, donc je le remarquerai ici:
MVN Clean échoue dans un projet multi-module lorsqu'il y a des dépendances manquantes dans le même projet, si les plugins sont invoqués pendant la propreté.
Nous invoquons le plug-in antrun pendant la phase propre dans certains modules et que toutes les dépendances doivent être présentes dans le référentiel Maven, y compris les autres modules du même réacteur, qui n'ont pas encore été construits dans certains cas. (Dites que vous venez de heurter la version du projet, ou vous déclenchez un nouveau projet).
Ceci est un bug maven-antrun signalé dans https: //issues.apache. org / jira / navigation / mantrun-78 - qui ramène à nouveau à un bug de Maven Core: https://issues.apache.org/jira/browse/mng-3283 .
Ma solution de contournement consistait à fournir aux développeurs (et à Jenkins) avec une autre façon de nettoyer (script shell / battonnet, script de fourmis ou une opération de nettoyage git / hg) et d'appeler cela à la place.
Je suggérerais une solution de contournement similaire pour votre équipe (ou je viens de configurer un référentiel maven partagé en interne dans votre équipe, utilisez l'une des machines de développeur si nécessaire).
Les liens mentionnés sont maintenant (02/2019) à Problèmes.apache.org/jira/Browse / Mantrun-78 et Problèmes.apache.org/jira/Browse/mng -3283
Merci, @ Alleen1. J'ai mis à jour les liens dans ma réponse.