Puis-je ajouter des jars au classpath de construction de maven 2 sans les installer ?

Question

Maven2 me rend fou pendant la phase d'expérimentation/de maquette rapide et sale du développement.

J'ai un fichier pom.xml qui définit les dépendances pour le framework web-app que je veux utiliser, et je peux rapidement générer des projets de démarrage à partir de ce fichier. Cependant, parfois je veux me lier à une bibliothèque tierce qui n'a pas encore de fichier pom.xml défini, donc plutôt que de créer le fichier pom.xml pour la bibliothèque tierce à la main et de l'installer, et d'ajouter la dépendance à mon pom.xml, je voudrais juste dire à maven : "En plus de mes dépendances définies, inclure tous les pots qui sont dans /lib aussi".

Il semble que cela devrait être simple, mais si c'est le cas, il me manque quelque chose.

Toute indication sur la manière de procéder est la bienvenue. En bref, s'il existe un moyen simple de faire pointer maven vers un répertoire /lib et de créer facilement un pom.xml avec toutes les jar jointes mappées à une dépendance unique que je pourrais ensuite nommer/installer et lier en une seule fois, cela suffirait également.

Answer 1

Problèmes des approches populaires

La plupart des réponses que vous trouverez sur Internet vous suggéreront soit d'installer la dépendance dans votre dépôt local, soit de spécifier une portée "système" dans le fichier de configuration de l'application. pom et distribuez la dépendance avec les sources de votre projet. Mais ces deux solutions sont en fait imparfaites.

Pourquoi ne pas appliquer l'approche "Installer dans le Repo 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 dépôt. 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. Il est clair que faire dépendre votre artefact d'une machine spécifique n'est pas une façon 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 bocaux dont vous dépendez avec l'approche "System Scope" ne sont ni installés dans un référentiel ni attachés à vos paquets cibles. C'est pourquoi votre paquet de distribution n'aura aucun moyen de résoudre cette dépendance lorsqu'il sera utilisé. Je crois que c'est la raison pour laquelle l'utilisation de la portée du système a été dépréciée. De toute façon, vous ne voulez pas vous reposer sur une fonctionnalité dépréciée.

La solution du 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 la forme x.y.z Maven inclura l'emplacement suivant dans votre répertoire de 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 .

Utiliser Maven pour installer le répertoire du projet

Au lieu de créer cette structure à la main, je recommande d'utiliser un plugin Maven pour installer vos jars comme artefacts. Ainsi, pour installer un artefact dans un dépôt dans le projet sous le nom de repo l'exécution du dossier :

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 dans le fichier pom à :

<repository>
    <id>repo</id>
    <url>file://${project.basedir}/repo</url>
</repository>

Une aide script

Puisque l'exécution de la commande d'installation pour chaque librairie est un peu ennuyeuse et certainement source d'erreurs, j'ai créé un fichier de type utilitaire script qui installe automatiquement tous les bocaux d'une lib à un dépôt de projet, tout en résolvant automatiquement toutes les métadonnées (groupId, artifactId et etc.) à partir des noms de fichiers. Le script imprime également le xml des dépendances pour que vous puissiez le copier-coller dans votre fichier pom .

Inclure les dépendances dans votre paquet cible

Lorsque vous aurez créé votre dépôt dans le projet, vous aurez résolu le problème de la distribution des dépendances du projet avec ses sources, mais depuis lors, l'artefact cible de votre projet dépendra de jars non publiés, donc lorsque vous l'installerez dans un dépôt, il aura des dépendances non résolues.

Pour résoudre ce problème, je suggère d'inclure ces dépendances dans votre paquetage cible. Vous pouvez le faire avec l'une des deux méthodes suivantes Plugin d'assemblage ou mieux avec le Plugin OneJar . La documentation officielle sur OneJar est facile à comprendre.

Answer 2

définir la portée == système et créer simplement un groupId, un artifactId et une version

<dependency>
    <groupId>org.swinglabs</groupId>
    <artifactId>swingx</artifactId>
    <version>0.9.2</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/swingx-0.9.3.jar</systemPath>
</dependency>

Answer 3

Vous pouvez créer un dépôt local sur votre projet.

Par exemple, si vous avez libs dans la structure du projet

• Sur libs vous devez créer une structure de répertoire comme suit /groupId/artifactId/version/artifactId-verion.jar

• Dans votre pom.xml, vous devez enregistrer le référentiel

<repository>

  <id>ProjectRepo</id>
  <name>ProjectRepo</name>
  <url>file://${project.basedir}/libs</url>

</repository>

• et ajoutez la dépendance comme d'habitude

<dependency>

   <groupId>groupId</groupId>
   <artifactId>artifactId</artifactId>
   <version>version</version>

</dependency>

C'est tout.

Pour des informations détaillées : Comment ajouter des bibliothèques externes dans Maven

Answer 4

Remarque : Lorsque vous utilisez le champ d'application du système ( comme mentionné sur cette page ), Maven a besoin de chemins absolus.

Si vos jars se trouvent sous la racine de votre projet, vous voudrez préfixer vos valeurs systemPath avec ${basedir}.

Answer 5

Vous devriez vraiment mettre en place un cadre de travail via un référentiel et identifier vos dépendances dès le départ. L'utilisation de la portée du système est une erreur courante des gens, car ils "ne se soucient pas de la gestion des dépendances". Le problème est qu'en faisant cela, vous vous retrouvez avec une construction maven pervertie qui ne montrera pas maven dans une condition normale. Vous feriez mieux de suivre une approche comme ce .