Installez le pot local avec Maven

1. Le problème et les options

Maven est un outil très polyvalent et ses référentiels publics disponibles sont incomparables. Cependant, il y aura toujours un artefact qui n'est soit hébergé nulle part , ou le référentiel où il est hébergé est risqué, car il peut ne pas être disponible lorsque vous en avez besoin.

Lorsque cela se produit, il y a quelques choix:

  • mordez la balle et installez une solution de gestion de référentiel à part entière telle que Nexus
  • essayez de télécharger l'artefact dans l'un des référentiels publics les plus réputés
  • installer l'artefact localement à l' aide d'un plugin maven

Nexus est bien sûr la solution la plus mature, mais c'est aussi la plus complexe . Provisionner une instance pour exécuter Nexus, configurer Nexus lui-même, la configurer et la maintenir peut être exagérée pour un problème aussi simple que l'utilisation d'un seul fichier jar. Si ce scénario - l'hébergement d'artefacts personnalisés - est cependant courant, un gestionnaire de référentiel a beaucoup de sens.

Obtenir l'artefact téléchargé directement dans un référentiel public ou dans Maven central est également une bonne solution, mais généralement longue. De plus, la bibliothèque peut ne pas être du tout activée par Maven, ce qui rend le processus beaucoup plus difficile, ce n'est donc pas une solution réaliste pour pouvoir utiliser l'artefact MAINTENANT.

Cela laisse la troisième option - ajouter l'artefact dans le contrôle de code source et utiliser un plugin maven - dans ce cas, le plugin maven-install pour l' installer localement avant que le processus de construction n'en ait besoin . C'est de loin l'option la plus simple et la plus fiable disponible.

2. Installez Local Jar avec le plugin m aven-install-plugin

Commençons par la configuration complète nécessaire pour installer l'artefact dans notre référentiel local:

 org.apache.maven.plugins maven-install-plugin 2.5.1  org.somegroup someartifact 1.0 jar ${basedir}/dependencies/someartifact-1.0.jar true    install-jar-lib  install-file  validate   

Maintenant, décomposons et analysons les détails de cette configuration.

2.1. Les informations sur l'artefact

Les informations sur les artefacts sont définies comme faisant partie du élément. La syntaxe réelle est très similaire à la déclaration de la dépendance - un groupId , un artifactId et des éléments de version .

La partie suivante de la configuration nécessite la définition de l' empaquetage de l'artefact - ceci est spécifié comme jar .

Ensuite, nous devons fournir l' emplacement du fichier jar à installer - cela peut être un chemin de fichier absolu ou il peut être relatif, en utilisant les propriétés disponibles dans Maven . Dans ce cas, la propriété $ {basedir} représente la racine du projet, à savoir l'emplacement où se trouve le fichier pom.xml . Cela signifie que le fichier someartifact-1.0.jar doit être placé dans un répertoire / dependencies / sous la racine.

Enfin, il existe plusieurs autres détails facultatifs qui peuvent également être configurés.

2.2. L'exécution

L'exécution de l' objectif du fichier d'installation est liée à la phase de validation du cycle de vie de construction standard de Maven. En tant que tel, avant d'essayer de compiler, vous devrez exécuter la phase de validation explicitement:

mvn validate

Après cette étape, la compilation standard fonctionnera:

mvn clean install

Une fois la phase de compilation exécutée , notre someartifact-1.0.jar est correctement installé dans notre référentiel local, tout comme tout autre artefact qui aurait pu être récupéré depuis le centre Maven lui-même.

2.3. Générer un POM vs Fournir le POM

La question de savoir si nous devons fournir un fichier pom.xml pour l'artefact ou non dépend principalement des dépendances d'exécution de l'artefact lui-même. En termes simples, si l'artefact a des dépendances d'exécution sur d'autres fichiers JAR, ces fichiers JAR devront également être présents sur le chemin de classe lors de l'exécution. Avec un artefact simple qui ne devrait pas poser de problème, car il n'aura probablement aucune dépendance au moment de l'exécution (une feuille dans le graphe de dépendances).

L' option generatePom dans l' objectif du fichier d'installation devrait suffire pour ces types d'artefacts:

true

Cependant, si l'artefact est plus complexe et a des dépendances non triviales , alors, si ces dépendances ne sont pas déjà dans le chemin de classe, elles doivent être ajoutées. Une façon de le faire est de définir ces nouvelles dépendances manuellement dans le fichier pom du projet. Une meilleure solution consiste à fournir un fichier pom.xml personnalisé avec l'artefact installé:

false ${basedir}/dependencies/someartifact-1.0.pom

Cela permettra à Maven de résoudre toutes les dépendances de l'artefact défini dans ce pom.xml personnalisé , sans avoir à les définir manuellement dans le fichier pom principal du projet.

3. Conclusion

Cet article explique comment utiliser un fichier jar qui n'est hébergé nulle part dans un projet Maven en l'installant localement avec le plugin maven-install-plugin .