Question Puis-je ajouter des jars à maven 2 buildpath sans les installer?


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

j'ai un pom.xml fichier qui définit les dépendances pour le framework d'application web que je veux utiliser, et je peux rapidement générer des projets de démarrage à partir de ce fichier. Cependant, parfois je veux créer un lien vers une bibliothèque tierce qui n'a pas déjà pom.xml fichier défini, donc plutôt que de créer le pom.xml fichier pour la 3ème partie lib à la main et l'installer, et 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.

Tout pointeur sur la façon de le faire est grandement apprécié. Bref, s'il y a un moyen simple de pointer maven vers un /lib répertoire et créer facilement un pom.xml avec tous les jars fermés mappés à une seule dépendance que je pourrais ensuite nommer / installer et lier en un seul coup suffirait aussi.


647
2017-12-12 20:57


origine


Réponses:


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 référentiel local, soit de spécifier une portée "système" dans le pom et distribuez la dépendance avec la source de votre projet. Mais ces deux solutions sont en réalité imparfaites.

Pourquoi ne pas appliquer l'approche "Install to Local Repo"

Lorsque vous installez une dépendance dans votre référentiel local, elle reste là. Votre artefact de distribution se passera 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éside sur votre machine locale, il n'y aura 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 fonctionnant avec ce projet, ce qui n'est pas mieux.

Pourquoi vous ne devez pas appliquer l'approche "System Scope"

Les jars dont vous dépendez avec l'approche "System Scope" ne sont pas installés dans un référentiel ou attachés à vos packages cibles. C'est pourquoi votre paquet de distribution n'aura aucun moyen de résoudre cette dépendance lorsqu'il est utilisé. Je crois que c'est la raison pour laquelle l'utilisation de la portée du système est devenue obsolète. De toute façon vous ne voulez pas compter sur 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 votre répertoire de projet dans sa recherche d'artefacts:

repo/
| - x/
|   | - y/
|   |   | - z/
|   |   |   | - ${artifactId}/
|   |   |   |   | - ${version}/
|   |   |   |   |   | - ${artifactId}-${version}.jar

Pour en savoir plus à ce sujet, vous pouvez lire ce blog.

Utiliser Maven pour installer le projet de repo

Au lieu de créer cette structure à la main, je recommande d'utiliser un plugin Maven pour installer vos pots comme des artefacts. Ainsi, pour installer un artefact dans un référentiel dans le projet sous repodossier exécuter:

mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]

Si vous choisissez cette approche, vous serez en mesure de simplifier la déclaration du référentiel dans pom à:

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

Un script d'aide

Depuis l'exécution de la commande d'installation pour chaque lib est un peu ennuyeux et certainement sujet à erreur, j'ai créé un script d'utilité qui installe automatiquement tous les pots 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.) à partir des noms de fichiers. Le script imprime également les dépendances xml pour que vous puissiez copier-coller dans votre pom.

Inclure les dépendances dans votre paquet cible

Lorsque vous aurez créé votre référentiel dans le projet, vous aurez résolu le problème de la distribution des dépendances du projet avec sa source, mais depuis, l'artefact cible de votre projet dépendra des jars non publiés, donc quand vous installerez à un dépôt, il aura des dépendances insolubles.

Pour contourner ce problème, je suggère d'inclure ces dépendances dans votre paquet cible. C'est ce que vous pouvez faire avec Plugin d'assemblage ou mieux avec le Plugin OneJar. La documentaion officielle sur OneJar est facile à saisir.


557
2017-10-02 00:15



Pour jeter le code seulement

Définissez scope == system et créez 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>

Remarque: les dépendances du système ne sont pas copiées dans le fichier jar / war
(voir Comment inclure les dépendances du système dans la guerre construit en utilisant maven)


460
2017-12-12 21:21



Vous pouvez créer un référentiel local sur votre projet

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

  • Dans libs dossier, vous devez créer une structure de répertoire comme: /groupId/artifactId/version/artifactId-version.jar

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

    <repository>
        <id>ProjectRepo</id>
        <name>ProjectRepo</name>
        <url>file://${project.basedir}/libs</url>
    </repository>
    
  • et ajouter 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


49
2017-10-05 13:01



Remarque: lorsque vous utilisez la portée du système (comme mentionné sur cette page), Maven a besoin de chemins absolus.

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


31
2018-01-08 21:58



Vous devriez vraiment avoir un cadre en place via un référentiel et identifier vos dépendances à l'avance. L'utilisation de la portée du système est une erreur courante que les gens utilisent, car ils «ne se soucient pas de la gestion des dépendances». Le problème est que, ce faisant, vous vous retrouvez avec une construction de Maven pervers qui ne montrera pas Maven dans un état normal. Vous feriez mieux de suivre une approche comme ce.


14
2018-04-19 02:16



C'est ce que j'ai fait, cela fonctionne également autour du problème du paquet et cela fonctionne avec le code extrait.

J'ai créé un nouveau dossier dans le projet dans mon cas, j'ai utilisé repo, mais n'hésitez pas à utiliser src/repo

Dans mon POM j'avais une dépendance qui ne se trouve dans aucun dépôt public de maven

<dependency>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <version>1.0.1</version>
    <scope>runtime</scope>
</dependency>

J'ai ensuite créé les répertoires suivants repo/com/dovetail/zoslog4j/1.0.1 et copié le fichier JAR dans ce dossier.

J'ai créé le fichier POM suivant pour représenter le fichier téléchargé (cette étape est optionnelle, mais il supprime un avertissement) et aide le prochain gars à comprendre où j'ai obtenu le fichier pour commencer.

<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <packaging>jar</packaging>
    <version>1.0.1</version>
    <name>z/OS Log4J Appenders</name>
    <url>http://dovetail.com/downloads/misc/index.html</url>
    <description>Apache Log4j Appender for z/OS Logstreams, files, etc.</description>
</project>

Deux fichiers facultatifs que je crée sont les sommes de contrôle SHA1 pour le POM et le JAR pour supprimer les avertissements de somme de contrôle manquants.

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar.sha1

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom.sha1

Enfin j'ajoute le fragment suivant à mon pom.xml qui me permet de me référer au référentiel local

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

12
2017-10-13 00:38



Maven install plugin a l'utilisation de la ligne de commande pour installer un pot dans le référentiel local, POM est facultatif mais vous devrez spécifier GroupId, ArtifactId, Version et Packaging (tous les trucs POM).


11
2018-01-08 22:23



Voici comment nous ajoutons ou installons un pot local

    <dependency>
        <groupId>org.example</groupId>
        <artifactId>iamajar</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/lib/iamajar.jar</systemPath>
    </dependency>

J'ai donné par défaut groupId et artefactId parce qu'ils sont obligatoires :)


10
2018-02-10 14:38



En utilisant <scope>system</scope> est une idée terrible pour des raisons expliquées par d'autres, l'installation du fichier manuellement dans votre référentiel local rend la construction non reproductible, et en utilisant <url>file://${project.basedir}/repo</url> n'est pas une bonne idée non plus parce que (1) cela peut ne pas être un file URL (par exemple si le projet est extrait dans un répertoire avec des caractères inhabituels), (2) le résultat est inutilisable si le POM de ce projet est utilisé comme dépendance du projet de quelqu'un d'autre.

En supposant que vous ne voulez pas télécharger l'artefact dans un dépôt public, la suggestion de Simeon d'un module d'assistance fait le travail. Mais il y a un moyen plus facile maintenant ...

La recommandation

Utilisation non-maven-jar-maven-plugin. Fait exactement ce que vous demandiez, sans aucun des inconvénients des autres approches.


8
2018-05-10 01:47