Installer 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 soit non hébergé nulle part , ou le référentiel où il est hébergé présente des risques, car il peut ne pas être opérationnel lorsque vous en avez besoin.

Lorsque cela se produit, il y a quelques choix:

mordre la balle et installer une gestion à part entière du dépôt

solution such as Nexus ** essayer d’obtenir l’artefact téléchargé dans l’un des public plus réputé

les dépôts installer l’artefact localement ** en utilisant un plugin maven

Nexus est bien sûr la solution la plus mature, mais c’est aussi la plus complexe ** . Approvisionner une instance pour exécuter Nexus, configurer Nexus lui-même, la configurer et la maintenir peut être excessif pour un problème aussi simple que celui d’utiliser un seul fichier jar. Si ce scénario - hébergement d’artefacts personnalisés - est courant, un gestionnaire de référentiel est tout à fait sensé.

Obtenir l’artefact téléchargé dans un référentiel public ou directement dans Maven central est également une bonne solution, mais généralement, il est long . De plus, il se peut que la bibliothèque ne soit pas du tout activée par Maven, ce qui rend le processus beaucoup plus difficile. Par conséquent, il n’est pas réaliste de pouvoir utiliser l’artéfact 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, the maven-install-plugin à installez-le localement avant que le processus de construction en ait besoin . C’est de loin l’option la plus facile et la plus fiable disponible.

2. Installer le fichier jar local avec le fichier maven-install-plugin

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

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-install-plugin</artifactId>
   <version>2.5.1</version>
   <configuration>
      <groupId>org.somegroup</groupId>
      <artifactId>someartifact</artifactId>
      <version>1.0</version>
      <packaging>jar</packaging>
      <file>${basedir}/dependencies/someartifact-1.0.jar</file>
      <generatePom>true</generatePom>
   </configuration>
   <executions>
      <execution>
         <id>install-jar-lib</id>
         <goals>
            <goal>install-file</goal>
         </goals>
         <phase>validate</phase>
      </execution>
   </executions>
</plugin>

Décomposons maintenant et analysons les détails de cette configuration.

2.1. Les informations sur l’artefact

Les informations sur l’artefact sont définies dans le cadre de l’élément <configuration> . La syntaxe réelle est très similaire à la déclaration de dépendance: des éléments groupId , artifactId et version .

La prochaine partie de la configuration nécessite de définir le packaging de l’artefact - spécifié sous la forme jar .

Ensuite, nous devons fournir l’emplacement du fichier jar à installer - il peut s’agir d’un chemin de fichier absolu ou relatif, à l’aide de https://cwiki.apache.org/confluence/display/MAVEN/Guide des propriétés Maven[propriétés]disponible dans Maven ** . Dans ce cas, la propriété $ \ {basedir} représente la racine du projet, à savoir l’emplacement du 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 http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html (détails optionnels)]pouvant également être configurés.

2.2. L’exécution

L’exécution de l’objectif install-file est liée à la phase ** validate du Maven standard build lifecycle . En tant que tel, avant de tenter de compiler, vous devez exécuter la phase de validation de manière explicite:

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, comme tout autre artefact éventuellement récupéré à partir de Maven central.

2.3. Générer un pom vs fournissant le pom

La question de savoir si nous devons ou non fournir un fichier pom.xml pour l’artefact 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 d’accès aux classes au moment de l’exécution. Avec un simple artefact, cela ne devrait pas poser de problème, car il n’aura probablement aucune dépendance à l’exécution (une feuille dans le graphique de dépendance).

L’option generatePom de l’objectif install-file devrait suffire pour ces types d’artefacts:

<generatePom>true</generatePom>

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

<generatePom>false</generatePom>
<pomFile>${basedir}/dependencies/someartifact-1.0.pom</pomFile>

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 pas hébergé dans un projet Maven en l’installant localement avec le fichier maven-install-plugin .

TOC