Comment ajouter des fichiers jar locaux à un projet Maven?

1171

Comment ajouter des fichiers jar locaux (qui ne font pas encore partie du référentiel Maven) directement dans les sources de bibliothèque de mon projet?

Praneel PIDIKITI
la source
1
Salut @Praneel PIDIKITI, Pouvez-vous s'il vous plaît changer la réponse acceptée à celle avec le plus de votes?
null
1
@nslntmnx Ce ne sera pas une meilleure solution, car toutes les solutions ont des inconvénients stackoverflow.com/questions/364114/…
Paul Verest
Si vos bibliothèques sont mises à jour ou étendues à l'occasion, consultez cette réponse à Je souhaite charger tous les fichiers JAR de mon dossier de projet de bibliothèques avec maven de manière "pomifiée" et éviter ainsi un dossier de dépôt supplémentaire et des lignes ou install-filescripts cmd encombrants .
GeroldBroser réintègre Monica le

Réponses:

699

Installez le fichier JAR dans votre référentiel Maven local comme suit:

mvn install:install-file \
   -Dfile=<path-to-file> \
   -DgroupId=<group-id> \
   -DartifactId=<artifact-id> \
   -Dversion=<version> \
   -Dpackaging=<packaging> \
   -DgeneratePom=true

Où chacun fait référence à:

<path-to-file>: le chemin du fichier à charger par exemple → c:\kaptcha-2.3.jar

<group-id>: le groupe dans lequel le fichier doit être enregistré, par exemple → com.google.code

<artifact-id>: le nom de l'artefact du fichier, par exemple → kaptcha

<version>: la version du fichier par exemple → 2.3

<packaging>: le packaging du fichier par exemple → jar

Référence

user373455
la source
7
Les instructions pour installer sur ma version avaient tout sauf la partie generatePom. Cela semble crucial.
Jason D
4
<path-to-file> qu'est-ce que cela signifie? Comme C: /Users/XXX/WorkspaceDocx/maven/src/main/resources/myJar.jar ...... ou pouvons-nous faire $ {project.basedir} /src/main/resources/myJar.jar
Igor Beaufils
17
La réponse ne mentionne pas un fichier README ou que les pots sont apportés. Cependant, si le projet apporte les pots, alors vous pourriez aussi bien mettre le dépôt dans le projet comme mentionné ici stackoverflow.com/a/36602256/1000011 alors vous n'avez pas besoin d'un fichier README car le projet fonctionnera comme si les pots étaient en maven central sans étapes manuelles supplémentaires.
opticyclique
8
@opticyclic votre commentaire a besoin de plus de votes positifs, ou cette réponse doit être modifiée. C'est une recette de désastre pour les novices qui ne réalisent pas que l'installation sur le dépôt Maven local n'inclurait pas tout le monde.
Mike S
3
Guide
Nick Graham
1431

Vous pouvez ajouter des dépendances locales directement (comme mentionné dans le projet build maven avec les bibliothèques de propriétés incluses ) comme ceci:

<dependency>
    <groupId>com.sample</groupId>
    <artifactId>sample</artifactId>
    <version>1.0</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/src/main/resources/Name_Your_JAR.jar</systemPath>
</dependency>

Mise à jour

Dans les nouvelles versions, cette fonctionnalité est marquée comme obsolète mais fonctionne toujours et n'est pas encore supprimée (vous voyez juste un avertissement dans le journal lors du démarrage de maven). Un problème est soulevé chez maven group à propos de ce https://issues.apache.org/jira/browse/MNG-6523 (vous pouvez participer et décrire pourquoi cette fonctionnalité est utile dans certains cas). J'espère que cette fonctionnalité restera là!

Si vous me demandez, tant que la fonctionnalité n'est pas supprimée, je l'utilise pour créer une dépendance à un seul fichier jar méchant dans mon projet qui ne rentre pas dans le référentiel. Si cette fonctionnalité est supprimée, eh bien, il y a beaucoup de bonnes réponses ici que je peux choisir plus tard!

Alireza Fattahi
la source
49
Il y a des moments où vous voulez tester spécifiquement un vieux pot par exemple, et je pense que cette réponse convient parfaitement à cela. C'est celui dont j'avais besoin. Vote positif
John Lockwood
36
Aussi agréable et simple qu'elle en a l'air, cette solution a le problème que yourJar.jar ne sera pas inclus dans un fichier WAR pour votre application.
Matthias
40
La solution ci-dessus ne fonctionne plus, elle renvoie: "'dependencies.dependency.systemPath' pour xx.jar ne doit pas pointer vers des fichiers dans le répertoire du projet" Cela a déjà été traité dans stackoverflow.com/questions/10935135/…
sarah .ferguson
8
Dans cette réponse, n'est-ce pas le mauvais artifactIdet groupIdle mauvais sens?
theonlygusti
5
Selon le docu Maven ( maven.apache.org/guides/introduction/… ): Remarque importante: Ceci est marqué comme obsolète.
agassner
142

Tout d'abord, je voudrais attribuer cette réponse à un utilisateur anonyme de Stack Overflow - je suis presque sûr d'avoir déjà vu une réponse similaire ici auparavant - mais maintenant je ne la trouve pas.

La meilleure option pour avoir des fichiers JAR locaux en tant que dépendance est de créer un référentiel Maven local. Un tel référentiel n'est rien d'autre qu'une structure de répertoires appropriée contenant des fichiers pom.

Pour mon exemple: j'ai mon projet principal sur ${master_project}place et subproject1 est activé ${master_project}/${subproject1}.

Puis - je créer un référentiel Maven dans: ${master_project}/local-maven-repo.

Dans le fichier pom dans subproject1 situé à ${master_project}/${subproject1}/pom.xml, le référentiel doit être spécifié qui prendra le chemin du fichier comme paramètre d'URL:

<repositories>
    <repository>
        <id>local-maven-repo</id>
        <url>file:///${project.parent.basedir}/local-maven-repo</url>
    </repository>
</repositories>

La dépendance peut être spécifiée comme pour tout autre référentiel. Cela rend votre référentiel pom indépendant. Par exemple, une fois que le fichier JAR souhaité est disponible dans Maven central, il vous suffit de le supprimer de votre référentiel local et il sera extrait du référentiel par défaut.

    <dependency>
        <groupId>org.apache.felix</groupId>
        <artifactId>org.apache.felix.servicebinder</artifactId>
        <version>0.9.0-SNAPSHOT</version>
    </dependency>

La dernière mais non la moindre chose à faire est d'ajouter le fichier JAR au référentiel local en utilisant le commutateur -DlocalRepositoryPath comme ceci:

mvn org.apache.maven.plugins:maven-install-plugin:2.5.2:install-file  \
    -Dfile=/some/path/on/my/local/filesystem/felix/servicebinder/target/org.apache.felix.servicebinder-0.9.0-SNAPSHOT.jar \
    -DgroupId=org.apache.felix -DartifactId=org.apache.felix.servicebinder \
    -Dversion=0.9.0-SNAPSHOT -Dpackaging=jar \
    -DlocalRepositoryPath=${master_project}/local-maven-repo

Une fois le fichier JAR installé, votre dépôt Maven peut être validé dans un référentiel de code et l'ensemble de la configuration est indépendant du système. ( Exemple de travail dans GitHub ).

Je conviens qu'avoir des JAR engagés dans le repo de code source n'est pas une bonne pratique, mais dans la vraie vie, des solutions rapides et sales sont parfois meilleures qu'un repo complet de Nexus pour héberger un JAR que vous ne pouvez pas publier.

JJ Roman
la source
Répertoire relatif local en tant que
dépôt maven
4
Si vous voulez le faire dans pom.xml, consultez baeldung.com/install-local-jar-with-maven
Kai Wang
@Kai Wang Cette solution fonctionne bien mieux! vous devriez peut-être ajouter ceci comme réponse.
lockwobr
7
Depuis ${project.parent.basedir}ne semble pas se résoudre à rien de nos jours, j'ai utilisé ${project.basedir}/..et travaillé parfaitement.
L'Empaleur du
1
Un conseil: veuillez vérifier $ HOME / .m2 / settings.xml , éviter que "local-maven-repo" ne soit reflété par settings / mirrors / mirror <mirrorOf>*</mirrorOf>.
btpka3
125

Créez un nouveau dossier, disons local-maven-repoà la racine de votre projet Maven.

Ajoutez simplement un dépôt local dans <project>votre pom.xml:

<repositories>
    <repository>
        <id>local-maven-repo</id>
        <url>file:///${project.basedir}/local-maven-repo</url>
    </repository>
</repositories>

Ensuite, pour chaque pot externe que vous souhaitez installer, allez à la racine de votre projet et exécutez:

mvn deploy:deploy-file -DgroupId=[GROUP] -DartifactId=[ARTIFACT] -Dversion=[VERS] -Durl=file:./local-maven-repo/ -DrepositoryId=local-maven-repo -DupdateReleaseInfo=true -Dfile=[FILE_PATH]
Anthony O.
la source
16
C'est la seule bonne réponse ici car elle créera votre référentiel correctement lors de l'utilisation de deploy.
opticyclique
Cette approche fonctionnerait-elle si le code était déployé à l'aide d'un serveur de génération CI? Il semble que les versions automatisées n'auraient pas accès à la dépendance.
Wallace Howery du
2
@ user2748659 oui si dans vos serveurs de builds CI le dossier local-maven-repoest inclus (en tant qu'enfant dans cet exemple) dans votre dossier source
Anthony O.
3
Cette réponse est ce qui a fonctionné pour moi. Pour un projet partagé, avoir le dépôt dans le répertoire du projet et ajouté au contrôle de version garantit que toute personne qui extrait le projet n'aura pas de dépendances manquantes. Si vous avez beaucoup de dépendances, alors un dépôt à distance partagé est probablement une meilleure solution, sinon garder le dépôt dans le répertoire du projet est parfaitement bien.
Aquarelle
2
Notez que pour ce faire, vous devrez peut-être ajouter -Dpackaging = jar. Sinon, vous obtenez "les informations sur l'artefact sont incomplètes ou invalides: l'emballage est manquant".
J Woodchuck
43

J'aimerais une telle solution - utiliser maven-install-plugindans le fichier pom:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-install-plugin</artifactId>
    <version>2.5.2</version>
    <executions>
        <execution>
            <phase>initialize</phase>
            <goals>
                <goal>install-file</goal>
            </goals>
            <configuration>
                <file>lib/yourJar.jar</file>
                <groupId>com.somegroup.id</groupId>
                <artifactId>artefact-id</artifactId>
                <version>x.y.z</version>
                <packaging>jar</packaging>
            </configuration>
        </execution>
    </executions>
</plugin>

Dans ce cas, vous pouvez effectuer mvn initializeet le pot sera installé dans le dépôt local de maven. Maintenant, ce pot est disponible pendant toute étape maven sur cette machine (n'oubliez pas d'inclure cette dépendance comme toute autre dépendance maven dans pom with <dependency></dependency>tag). Il est également possible de lier l'installation de jar non pas à l' initializeétape, mais à toute autre étape que vous aimez.

sphinks
la source
2
Cela fonctionne bien pour moi, mais seulement si je lance mvn initializeavant mvn package: je ne peux pas mvn initialize packageou bien il essaie de télécharger le JAR à partir du référentiel central. Pourquoi est-ce? Je pensais qu'il exécuterait ces objectifs / phases dans l'ordre.
DavidS
1
En fait, ils doivent être exécutés dans l'ordre. Jetez un œil à la liste des cycles de vie par défaut: maven.apache.org/guides/introduction/… Vous pouvez utiliser une autre étape pour effectuer la liaison.
sphinks
2
J'ai essayé toutes les méthodes, mais j'ai finalement dû recourir à cette solution. La raison principale est que je voulais pouvoir construire localement les packages en mode hors ligne. Si je l'ai déclaré comme une dépendance avec un référentiel défini localement, cela a toujours été considéré comme un simple dépôt en ligne et la génération maven s'est plainte de ne pas infliger d'amende à l'artefact. Cette solution fonctionne bien pour chaque cas.
Mauli
2
Je pense qu'il est préférable d'utiliser une phase propre car l'initialisation sera exécutée à chaque fois que nous utiliserons le package mvn lorsque ce n'est pas nécessaire. Enfin, si nous n'avons besoin que de générer le pot / war, nous pouvons utiliser directement le package propre mvn .
Deoxyseia
" Il est également possible de lier l'installation de jar pour ne pas initialiser l'étape, mais toute autre étape que vous aimez. " N'est pas nécessairement vrai. Si la dépendance n'est pas encore dans le référentiel et qu'une phase est utilisée après une phase qui résout les dépendances (par exemple compile), la construction échouera.
GeroldBroser réintègre Monica le
29
<dependency>
    <groupId>group id name</groupId>
    <artifactId>artifact name</artifactId>
    <version>version number</version>
    <scope>system</scope>
    <systemPath>jar location</systemPath>
</dependency>
Satish Karuturi
la source
6
<scope>systemest obsolète maintenant.
GeroldBroser réintègre Monica le
@GeroldBroser - ok. que pouvons-nous utiliser à la place de cela?
MasterJoe2
2
@ MasterJoe2 Comme également mentionné dans la réponse acceptée, install:install-file l'artefact au référentiel local et l'utiliser comme une dépendance "normale" (avec la portée par défaut compile) ou utiliser une solution de référentiel dans le projet .
GeroldBroser réintègre Monica
14

Le moyen vraiment rapide et sale est de pointer vers un fichier local:

<dependency>
      <groupId>sample</groupId>  
       <artifactId>com.sample</artifactId>  
       <version>1.0</version> 
      <scope>system</scope>
      <systemPath>C:\DEV\myfunnylib\yourJar.jar</systemPath>
</dependency>

Cependant, cela ne vivra que sur votre machine (évidemment), car le partage a généralement du sens d'utiliser une archive m2 appropriée (nexus / artifactory) ou si vous n'en avez pas ou si vous ne voulez pas en créer un de maven local archive structurée et configurez un "référentiel" dans votre pom: local:

<repositories>
    <repository>
        <id>my-local-repo</id>
        <url>file://C:/DEV//mymvnrepo</url>
    </repository>
</repositories>

éloigné:

<repositories>
    <repository>
        <id>my-remote-repo</id>
        <url>http://192.168.0.1/whatever/mavenserver/youwant/repo</url>
    </repository>
</repositories>

pour cela un chemin relatif est également possible en utilisant la variable basedir:

<url>file:${basedir}</url>
fl0w
la source
Pour les URL de référentiel local, peuvent-elles être relatives ou doivent-elles être absolues?
Dragas
@Dragas Je n'ai pas essayé, veuillez nous en informer si vous l'avez fait.
fl0w
1
Ouais, apparemment, vous devez utiliser <url>file:${basedir}</url>comme URL de base à la place.
Dragas
11

Ajoutez votre propre JAR local dans le fichier POM et utilisez-le dans la construction maven.

mvn install:install-file -Dfile=path-to-jar -DgroupId=owngroupid -DartifactId=ownartifactid -Dversion=ownversion -Dpackaging=jar

Par exemple:

mvn install:install-file -Dfile=path-to-jar -DgroupId=com.decompiler -DartifactId=jd-core-java -Dversion=1.2 -Dpackaging=jar

Ajoutez-le ensuite au POM comme ceci:

entrez la description de l'image ici

Tummidi Phani Kumar
la source
J'obtiens une erreur Échec de l'installation de l'artefact (accès refusé). Comment puis-je resoudre ceci? @Aurasphere
Ramzah Rehman
1
@RamzahRehman essayez d'ouvrir l'invite de commande avec les privilèges admi en cliquant dessus avec le bouton droit puis en choisissant "Exécuter en tant qu'administrateur"
Aurasphere
9

Une façon consiste à le télécharger sur votre propre gestionnaire de référentiel Maven (tel que Nexus). C'est une bonne pratique d'avoir de toute façon un gestionnaire de référentiel.

Une autre façon intéressante que j'ai récemment vue est d'inclure le plugin d'installation Maven dans votre cycle de vie de build: vous déclarez dans le POM d'installer les fichiers dans le référentiel local. C'est un peu mais peu de frais généraux et aucune étape manuelle n'est impliquée.

http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html

Puce
la source
4
Finissez par passer à gradle. Cela ne fonctionne pas Si le jar local est défini comme des dépendances, maven n'exécutera pas de plugins avant de résoudre les dépendances, une installation manuelle est inévitable. a trouvé une discussion sur cette situation: stackoverflow.com/questions/5951999/…
xinthink
6

Un autre cas intéressant est lorsque vous souhaitez avoir dans votre projet des pots maven privés. Vous souhaiterez peut-être conserver les capacités de Maven pour résoudre les dépendances transitives. La solution est assez simple.

  1. Créez un dossier libs dans votre projet
  2. Ajoutez les lignes suivantes dans votre fichier pom.xml

    <properties><local.repository.folder>${pom.basedir}/libs/</local.repository.folder>
    </properties>
    
    <repositories>
       <repository>
            <id>local-maven-repository</id>
            <url>file://${local.repository.folder}</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
       </repository>
    </repositories>
  3. Ouvrez le dossier .m2 / repository et copiez la structure de répertoires du projet que vous souhaitez importer dans le dossier libs .

Par exemple, supposons que vous souhaitiez importer la dépendance

<dependency>
    <groupId>com.mycompany.myproject</groupId>
    <artifactId>myproject</artifactId>
    <version>1.2.3</version>
</dependency>

Allez sur .m2 / repository et vous verrez le dossier suivant

com / mycompany / myproject / 1.2.3

Copiez tout dans votre dossier libs (encore une fois, y compris les dossiers sous .m2 / repository ) et vous avez terminé.

Jean Valjean
la source
6

ligne de commande :

mvn install:install-file -Dfile=c:\kaptcha-{version}.jar -DgroupId=com.google.code
-DartifactId=kaptcha -Dversion={version} -Dpackaging=jar
Hassani
la source
5

La partie importante de la dépendance est: $ {pom.basedir} (au lieu de seulement $ {basedir})

<dependency>
    <groupId>org.example</groupId>
    <artifactId>example</artifactId>
    <version>1.0</version>
    <scope>system</scope>
    <systemPath>${pom.basedir}/src/lib/example.jar</systemPath>
</dependency>
kolle_86
la source
4

Je pense qu'une meilleure solution à ce problème consiste à utiliser maven-install-plugin pour installer automatiquement les fichiers au moment de l'installation. C'est ainsi que je l'ai configuré pour mon projet.

Tout d'abord, ajoutez le chemin (où vous stockez les .jars locaux) en tant que propriété.

<properties>
    <local.sdk>/path/to/jar</local.sdk>
</properties>

Ensuite, sous pluginsajouter un plugin pour installer les pots lors de la compilation.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-install-plugin</artifactId>
    <version>2.5.2</version>
    <executions>
        <execution>
            <id>1</id>
            <phase>initialize</phase>
            <goals>
                <goal>install-file</goal>
            </goals>
            <configuration>
                <groupId>com.local.jar</groupId> 
                <artifactId>appengine-api</artifactId>
                <version>1.0</version>
                <packaging>jar</packaging>
                <file>${local.sdk}/lib/impl/appengine-api.jar</file>
            </configuration>
        </execution>
        <execution>
            <id>appengine-api-stubs</id>
            <phase>initialize</phase>
            <goals>
                <goal>install-file</goal>
            </goals>
            <configuration>
                <groupId>com.local.jar</groupId>
                <artifactId>appengine-api-stubs</artifactId>
                <version>1.0</version>
                <packaging>jar</packaging>
                <file>${local.sdk}/lib/impl/appengine-api-stubs.jar</file>
            </configuration>
        </execution>
    </executions>
</plugin>

Enfin, dans les dépendances, vous pouvez ajouter les pots

<dependency>
    <groupId>com.local.jar</groupId>
    <artifactId>appengine-api</artifactId>
    <version>1.0</version>
</dependency>

<dependency>
    <groupId>com.local.jar</groupId>
    <artifactId>appengine-api-stubs</artifactId>
    <version>1.0</version>
    <scope>test</scope>
</dependency>

En configurant votre projet comme ceci, le projet continuera à être construit même lorsque vous le portez à un autre ordinateur (étant donné qu'il a tous les fichiers jar dans le chemin spécifié par la propriété local.sdk).

Pour groupIdutiliser un nom unique juste pour vous assurer qu'il n'y a pas de conflits.

Maintenant, lorsque vous mvn installou mvn testles pots locaux seront ajoutés automatiquement.

Sudara
la source
3

La manière préférée serait de créer votre propre référentiel distant.

Voir ici pour plus de détails sur la façon de le faire. Jetez un œil à la section « Téléchargement vers un référentiel distant ».

Siméon
la source
3

Je veux partager un code où vous pouvez télécharger un dossier plein de pots. C'est utile lorsqu'un fournisseur n'a pas de référentiel public et que vous devez ajouter de nombreuses bibliothèques manuellement. J'ai décidé de créer un .bat au lieu d'appeler directement à maven car il pourrait s'agir d'erreurs de mémoire insuffisante. Il a été préparé pour un environnement Windows mais est facile à adapter à Linux OS:

import java.io.File;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Date;
import java.util.jar.Attributes;
import java.util.jar.JarFile;
import java.util.jar.Manifest;

public class CreateMavenRepoApp {

    private static final String OCB_PLUGIN_FOLDER = "C://your_folder_with_jars";

    public static void main(String[] args) throws IOException {

    File directory = new File();
    //get all the files from a directory
    PrintWriter writer = new PrintWriter("update_repo_maven.bat", "UTF-8");
    writer.println("rem "+ new Date());  
    File[] fList = directory.listFiles();
    for (File file : fList){
        if (file.isFile()){               
        String absolutePath = file.getAbsolutePath() ;
        Manifest  m = new JarFile(absolutePath).getManifest();
        Attributes attributes = m.getMainAttributes();
        String symbolicName = attributes.getValue("Bundle-SymbolicName");

        if(symbolicName!=null &&symbolicName.contains("com.yourCompany.yourProject")) {
            String[] parts =symbolicName.split("\\.");
            String artifactId = parts[parts.length-1];
            String groupId = symbolicName.substring(0,symbolicName.length()-artifactId.length()-1);
            String version = attributes.getValue("Bundle-Version");
            String mavenLine= "call mvn org.apache.maven.plugins:maven-install-plugin:2.5.1:install-file -Dfile="+ absolutePath+" -DgroupId="+ groupId+" -DartifactId="+ artifactId+" -Dversion="+ version+" -Dpackaging=jar ";
            writer.println(mavenLine);          
        }

        }
    }
    writer.close();
    }

}

Après avoir exécuté ce principal à partir de n'importe quel IDE, exécutez update_repo_maven.bat.

Luis Muzikant
la source
Votre code String symbolicName = attributes.getValue("Bundle-SymbolicName"); if(symbolicName!=null &&symbolicName.contains("com.yourCompany.yourProject"))semble indiquer que seuls les pots personnalisés seront pris en charge. Ce n'est pas ce dont nous avons besoin: plutôt un tas de pots tiers. Avez-vous des suggestions pour installer un pot de cette façon?
javadba
J'ai corrigé votre code: j'ai mis une réponse en bas.
javadba
3

Il s'agit d'une syntaxe courte pour les versions les plus récentes:

mvn install:install-file -Dfile=<path-to-file>

Cela fonctionne lorsque le JAR a été construit par Apache Maven - le cas le plus courant. Ensuite, il contiendra un pom.xml dans un sous-dossier du répertoire META-INF, qui sera lu par défaut.

Source: http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html

joro
la source
2

Jetez également un œil à ...

<scope>compile</scope>

Dépendances Maven . Il s'agit de la valeur par défaut, mais dans certains cas, j'ai explicitement défini cette portée également Maven pour rechercher des bibliothèques locales dans le référentiel local.

kervin
la source
2

Pour une raison quelconque, dans l'application Web à laquelle je fais de la maintenance, ni la solution d'Alireza Fattahi ni la solution de JJ Roman ne fonctionnaient correctement. Dans les deux cas, la compilation se passe bien (elle voit le pot), mais l'emballage ne parvient pas à inclure le pot à l'intérieur de la guerre.

La seule façon dont j'ai réussi à le faire fonctionner était de mettre le pot /src/main/webapp/WEB-INF/lib/et de le combiner avec la solution de Fattahis ou de Roman.

Haroldo_OK
la source
1

Notez que ce n'est PAS nécessairement une bonne idée d'utiliser un dépôt local. Si ce projet est partagé avec d'autres, tout le monde aura des problèmes et des questions lorsqu'il ne fonctionnera pas, et le pot ne sera pas disponible même dans votre système de contrôle de source!

Bien que le dépôt partagé soit la meilleure réponse, si vous ne pouvez pas le faire pour une raison quelconque, l'intégration du pot est meilleure qu'un dépôt local. Le contenu du dépôt local uniquement peut provoquer de nombreux problèmes, en particulier au fil du temps.

Franc
la source
1
si vous ajoutez les pots dans le système de contrôle de source, les bibliothèques seront toujours disponibles avec la source. Aucune source, aucune bibliothèque. Avec maven, la source peut être correcte, mais le référentiel n'est pas disponible.
sarah.ferguson
@Frank ... une idée sur la façon de créer un fichier exécutable sans inclure les dépendances externes (fichiers de bibliothèque)?
Satish Karuturi
Pour quelqu'un qui découvre Maven et qui cherche une réponse à la question d'origine, que signifie «intégrer le pot»?
cdock
1

Sur votre référentiel local, vous pouvez installer votre pot en émettant les commandes

 mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> \
-DartifactId=<artifact-id> -Dversion=<version> -Dpackaging=<packaging>

Suivez ce lien utile pour faire de même depuis le site Web de mkyoung. Vous pouvez également consulter le guide maven pour le même

bpjoshi
la source
1

Pour installer un pot tiers, veuillez appeler la commande comme ci-dessous

mvn install:install-file -DgroupId= -DartifactId= -Dversion= -Dpackaging=jar -Dfile=path
Ravikiran Reddy Kotapati
la source
1
  1. installation mvn

Vous pouvez écrire du code ci-dessous en ligne de commande ou si vous utilisez eclipse builtin maven, faites un clic droit sur le projet -> Exécuter en tant que -> exécuter les configurations ... -> dans le panneau de gauche, cliquez avec le bouton droit sur Maven Build -> nouvelle configuration -> écrivez le code dans les objectifs et dans le répertoire de base: $ {project_loc: NameOfYourProject} -> Run

mvn install:install-file
   -Dfile=<path-to-file>
   -DgroupId=<group-id>
   -DartifactId=<artifact-id>
   -Dversion=<version>
   -Dpackaging=<packaging>
   -DgeneratePom=true

Où chacun fait référence à:

<chemin d'accès au fichier>: le chemin d'accès au fichier à charger, par exemple -> c: \ kaptcha-2.3.jar

<group-id>: le groupe dans lequel le fichier doit être enregistré, par exemple -> com.google.code

<artifact-id>: le nom de l'artefact du fichier, par exemple -> kaptcha

<version>: la version du fichier par exemple -> 2.3

<packaging>: le packaging du fichier par exemple -> jar

2.Après l'installation, déclare simplement le fichier jar dans pom.xml.

 <dependency>
      <groupId>com.google.code</groupId>
      <artifactId>kaptcha</artifactId>
      <version>2.3</version>
 </dependency>
Mazen Embaby
la source
1

Étape 1: configurez le maven-install-pluginavec l'objectif install-filedans votrepom.xml

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-install-plugin</artifactId>
    <executions>
        <execution>
            <id>install-external-non-maven-jar-MWS-Client-into-local-maven-repo</id>
            <phase>clean</phase>
            <configuration>
                <repositoryLayout>default</repositoryLayout>
                <groupId>com.amazonservices.mws</groupId>
                <artifactId>mws-client</artifactId>
                <version>1.0</version>
                <file>${project.basedir}/lib/MWSClientJavaRuntime-1.0.jar</file>
                <packaging>jar</packaging>
                <generatePom>true</generatePom>
            </configuration>
            <goals>
                <goal>install-file</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Assurez-vous de modifier le filechemin en fonction de votre chemin de fichier réel (il est recommandé de placer ces pots externes non-maven dans un dossier, disons lib, et de placer celib dossier dans votre projet afin d'utiliser le chemin relatif spécifique au projet et d'éviter d'ajouter un système chemin absolu spécifique.

Si vous avez plusieurs pots externes, répétez simplement les <execution>autres pots du mêmemaven-install-plugin .

Étape 2: Une fois que vous avez configuré le maven-install-plugincomme indiqué ci-dessus dans votre pom.xmlfichier, vous devez utiliser ces pots dans votre pom.xmlcomme d'habitude:

    <dependency>
        <groupId>com.amazonservices.mws</groupId>
        <artifactId>mws-client</artifactId>
        <version>1.0</version>
    </dependency>

Notez que les maven-install-pluginseules copies de vos pots externes vers votre local.m2 référentiel maven . C'est ça. Il n'inclut pas automatiquement ces fichiers jar en tant que dépendances maven dans votre projet.

C'est un point mineur, mais parfois facile à manquer.

Yatendra Goel
la source
0

J'ai eu la même erreur pour un ensemble de dépendances dans mon pom.xml, il s'avère que les versions des dépendances n'étaient pas spécifiées dans le pom.xml et étaient mentionnées dans le référentiel parent. Pour une raison quelconque, les détails de la version n'étaient pas synchronisés avec ce dépôt. Par conséquent, j'ai entré manuellement les versions à l'aide de la balise et cela a fonctionné comme un charme. Peu de temps nécessaire pour rechercher les versions dans le parent et spécifier ici. Mais cela peut être fait uniquement pour les pots qui montrent l'erreur d'artefactide et cela fonctionne. J'espère que cela aide quelqu'un.

Ranjan Rozario
la source
0

Dans Apache Maven 3.5.4, j'ai dû ajouter une double citation. Sans double devis, cela n'a pas fonctionné pour moi.

exemple: mvn install: fichier-install "-Dfile = emplacement dans le fichier jar" "-DgroupId = id groupe" "-DartifactId = id artefact" "-Dversion = version" "-Dpackaging = type de package"

Kavindu Gayan
la source
0
  1. Créez un répertoire de référentiel Maven local, la racine de votre projet devrait ressembler à ceci pour commencer:
yourproject
+- pom.xml
+- src
  1. Ajoutez un répertoire de référentiel Maven standard appelé repo pour le groupe com.example et la version 1.0:
yourproject
+- pom.xml
+- src
+- repo
  1. Déployez l'artefact dans le référentiel, Maven peut déployer l'artefact pour vous à l'aide de l'objectif mvn deploy: deploy-file:
mvn deploy:deploy-file -Durl=file:///pathtoyour/repo -Dfile=your.jar -DgroupId=your.group.id -DartifactId=yourid -Dpackaging=jar -Dversion=1.0
  1. installez le fichier pom correspondant à votre jar pour que votre projet puisse trouver le jar lors de la construction de maven à partir du référentiel local:
mvn install:install-file -Dfile=/path-to-your-jar-1.0.jar -DpomFile=/path-to-your-pom-1.0.pom
  1. ajoutez un repo dans votre fichier pom:
<repositories>
    <!--other repositories if any-->
    <repository>
        <id>project.local</id>
        <name>project</name>
        <url>file:${project.basedir}/repo</url>
    </repository>
</repositories>
  1. ajoutez la dépendance dans votre pom:
<dependency>
    <groupId>com.groupid</groupId>
    <artifactId>myid</artifactId>
    <version>1.0</version>
</dependency>
Dean Jain
la source
-2

CETTE RÉPONSE EST UNIQUEMENT POUR LES UTILISATEURS D'ECLIPSE:

Si vous utilisez Eclipse, placez le pot dans lib /, faites un clic droit sur le nom du pot et cliquez sur "ajouter au chemin de construction". Eclipse créera une "bibliothèques référencées" et placera le pot pour vous

Il a résolu l'importation du pot immédiatement dans le programme pour moi

Anandkumar
la source
5
Cela ajoutera une entrée dans Eclipse .classpath, mais votre build mvn packagemaven sera brocket une fois que vous commencerez à utiliser cette dépendance, car maven n'en a pas de définition, et cela ne devrait être que danspom.xml
Paul Verest
oui, vous avez raison, le paquet ne comprendra pas le pot local. Mais j'ai répondu à la question, comment l'ajouter à un projet (de manière éclipse).
Anandkumar