Maven se déploie sur Nexus

Dansa previous article, j'ai expliqué comment un projet Maven peut installer localement un fichier jar tiers qui n'a pas encore été déployé sur Maven Central (ou sur l'un des autres grands référentiels hébergés publiquement).

Cette solution ne devrait être appliquée que dans de petits projets où l'installation, l'exécution et la maintenance d'un serveur Nexus complet risquent d'être excessifs. Cependant, à mesure que le projet se développe,

Nexus devient rapidement la seule option réelle et mature pour l'hébergement d'artefacts tiers, ainsi que pour la réutilisation d'artefacts internes dans des flux de développement.

Cet article montre comment déployer les artefacts d'un projetto Nexus, with Maven.

Pour que Maven puisse déployer les artefacts qu'il crée dans la phasepackage de la construction, il doit définir les informations du référentiel où les artefacts packagés seront déployés, via l'élémentdistributionManagement:

Un référentielSnapshots public hébergé est prêt à l'emploi sur Nexus, il n'est donc pas nécessaire de créer ou de configurer quoi que ce soit. Nexus facilite la détermination des URL de ses référentiels hébergés - chaque référentiel affiche l'entrée exacte à ajouter dans les<distributionManagement> du projet pom, sous l'ongletSummary.

Par défaut, Maven gère le mécanisme de déploiement via lemaven-deploy-plugin - il est mappé à la phasedeployment du cycle de vie Maven par défaut:

Lemaven-deploy-plugin est une option viable pour gérer la tâche de déploiement sur les artefacts d'un projet vers Nexus, mais il n'a pas été conçu pour tirer pleinement parti de ce que Nexus a à offrir. De ce fait, Sonatype a construit un plugin spécifique à Nexus - lenexus-staging-maven-plugin - qui est en fait conçu pour tirer pleinement parti des fonctionnalités plus avancées que Nexus a à offrir - des fonctionnalités telles que la mise en scène.

Bien que, pour un processus de déploiement simple, nous n’exigeons pas de fonctionnalité de transfert, nous allons utiliser ce plug-in Nexus personnalisé, car il a été conçu dans le but clair de bien communiquer avec Nexus.

La seule raison d'utiliser lesmaven-deploy-plugin est de garder ouverte l'option d'utiliser une alternative à Nexus à l'avenir - par exemple, un référentielArtifactory. Toutefois, contrairement aux autres composants susceptibles de changer tout au long du cycle de vie d'un projet, il est très peu probable que Maven Repository Manager change, de sorte qu'une flexibilité n'est pas requise.

Ainsi, la première étape pour utiliser un autre plug-in de déploiement dans la phase de déploiement consiste à désactiver le mappage existant par défaut:

Maintenant, nous pouvons définir:

L'objectifdeploy du plugin est mappé à la phasedeploy de la construction Maven.

Notez également que, comme discuté, nous n'avons pas besoin de fonctionnalité de transfert dans un simple déploiement d'artefacts-SNAPSHOT sur Nexus, donc cela est complètement désactivé via l'élément<skipStaging>.

Par défaut, l'objectif de déploiement inclut le flux de travaux de transfert, recommandé pour les versions validées.

Le déploiement sur Nexus est unsecured operation - et un utilisateurdeployment existe à cette fin sur n'importe quelle instance Nexus.

La configuration de Maven avec les informations d'identification de cet utilisateurdeployment, afin qu'il puisse interagir correctement avec Nexus, ne peut pas être effectuée dans lespom.xml du projet. C'est parce que la syntaxe despom ne le permet pas, sans parler du fait que lespom peuvent être un artefact public, donc pas bien adapté pour contenir des informations d'identification.

Les informations d'identification du serveur doivent être définies dans les Mavensetting.xmlglobaux:

Le serveur peut également être configuré pour utiliser une sécurité basée sur une clé plutôt que des informations d'identification brutes et en texte brut.

Effectuer le processus de déploiement est une tâche simple:

Sauter les tests est acceptable dans le contexte d'un travail de déploiement car ce travail doit être le dernier travail d'undeployment pipeline pour le projet.

Un exemple courant d'un tel pipeline de déploiement serait une succession de travaux Jenkins, chacun déclenchant le suivant uniquement s'il aboutit. En tant que tel, il est de la responsabilité des travaux précédents du pipeline d'exécuter toutes les suites de tests du projet - au moment où le travail de déploiement s'exécute, tous les tests doivent déjà être réussis.

Si une seule commande est exécutée, les tests peuvent être maintenus actifs pour s’exécuter avant l’exécution de la phasedeployment:

Il s’agit d’une solution simple, mais très efficace, pour déployer des artefacts Maven vers Nexus.

Il est également quelque peu opiniâtre -nexus-staging-maven-plugin est utilisé à la place dumaven-deploy-plugin par défaut; la fonctionnalité de transfert est désactivée, etc. - ce sont ces choix qui rendent la solution simple et pratique.

L'activation potentielle de la fonctionnalité de transfert complet peut être le sujet d'un futur article.

Enfin, nous aborderons le processus de publication dans le prochain article.