Problèmes des approches populaires
La plupart des réponses que vous trouverez sur Internet vous suggéreront d'installer la dépendance dans votre référentiel local ou de spécifier une étendue "système" dans le pom
et de distribuer la dépendance avec la source de votre projet. Mais ces deux solutions sont en fait imparfaites.
Pourquoi vous ne devriez pas appliquer l'approche "Installer sur le référentiel local"
Lorsque vous installez une dépendance dans votre référentiel local, elle y reste. Votre artefact de distribution fonctionnera bien tant qu'il aura accès à ce référentiel. Le problème est que dans la plupart des cas, ce référentiel résidera sur votre machine locale, il n'y aura donc aucun moyen de résoudre cette dépendance sur une autre machine. Clairement, faire dépendre votre artefact d'une machine spécifique n'est pas un moyen de gérer les choses. Sinon, cette dépendance devra être installée localement sur chaque machine travaillant avec ce projet, ce qui n'est pas mieux.
Pourquoi ne pas appliquer l'approche "System Scope"
Les jars dont vous dépendez avec l'approche "System Scope" ne sont ni installés dans aucun référentiel ni attachés à vos packages cibles. C'est pourquoi votre package de distribution n'aura aucun moyen de résoudre cette dépendance lorsqu'il est utilisé. Je pense que c'est la raison pour laquelle l'utilisation de la portée du système a même été déconseillée. Quoi qu'il en soit, vous ne voulez pas vous fier à une fonctionnalité obsolète.
La solution de référentiel statique dans le projet
Après avoir mis cela dans votre pom
:
<repository>
<id>repo</id>
<releases>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
<url>file://${project.basedir}/repo</url>
</repository>
pour chaque artefact avec un identifiant de groupe de forme, x.y.z
Maven inclura l'emplacement suivant dans le répertoire de votre projet dans sa recherche d'artefacts:
repo/
| - x/
| | - y/
| | | - z/
| | | | - ${artifactId}/
| | | | | - ${version}/
| | | | | | - ${artifactId}-${version}.jar
Pour en savoir plus, vous pouvez lire cet article de blog .
Utilisez Maven pour installer le projet repo
Au lieu de créer cette structure à la main, je recommande d'utiliser un plugin Maven pour installer vos pots en tant qu'artefacts. Ainsi, pour installer un artefact dans un référentiel dans le projet sous repo
dossier, exécutez:
mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]
Si vous choisissez cette approche, vous pourrez simplifier la déclaration du référentiel pom
pour:
<repository>
<id>repo</id>
<url>file://${project.basedir}/repo</url>
</repository>
Un script d'aide
Étant donné que l'exécution de la commande d'installation pour chaque bibliothèque est un peu ennuyeuse et propice aux erreurs, j'ai créé un script utilitaire qui installe automatiquement tous les fichiers jars d'un lib
dossier vers un référentiel de projet, tout en résolvant automatiquement toutes les métadonnées (groupId, artifactId et etc.) de noms des fichiers. Le script affiche également les dépendances xml que vous pouvez copier-coller dans votre pom
.
Inclure les dépendances dans votre package cible
Lorsque vous aurez créé votre référentiel dans le projet, vous aurez résolu un problème de distribution des dépendances du projet avec sa source, mais depuis lors, l'artefact cible de votre projet dépendra de fichiers JAR non publiés, donc quand vous installerez vers un référentiel, il aura des dépendances insolubles.
Pour surmonter ce problème, je suggère d'inclure ces dépendances dans votre package cible. Vous pouvez le faire avec le plugin Assembly ou mieux avec le plugin OneJar . La documentation officielle sur OneJar est facile à saisir.