web-dev-qa-db-fra.com

Maven: ajoute une dépendance à un jar par chemin relatif

J'ai un bocal propriétaire que je veux ajouter à mon pom en tant que dépendance.

Mais je ne veux pas l'ajouter à un référentiel. La raison en est que je veux que mes commandes Maven habituelles telles que mvn compile, etc., fonctionnent immédiatement. (Sans demander aux développeurs de l'ajouter à un dépôt par eux-mêmes).

Je veux que le fichier jar se trouve dans une bibliothèque tierce dans le contrôle de code source et soit lié à celui-ci par un chemin relatif à partir du fichier pom.xml.

Cela peut-il être fait? Comment?

218
flybywire

Je veux que le fichier jar se trouve dans une bibliothèque tierce dans le contrôle de code source et soit lié à celui-ci par un chemin relatif à partir du fichier pom.xml.

Si vous voulez vraiment ceci (comprenez, si vous ne pouvez pas utiliser un référentiel d'entreprise), alors je vous conseillerais d'utiliser un "référentiel de fichiers" local pour le projet et de ne pas utiliser une dépendance system. La portée system doit être évitée, de telles dépendances ne fonctionnent pas bien dans de nombreuses situations (par exemple dans Assembly), elles causent plus de problèmes que d’avantages.

Donc, déclarez plutôt un référentiel local au projet:

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

Installez là votre bibliothèque tierce en utilisant install:install-file avec le paramètre localRepositoryPath :

mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> \ 
                         -DartifactId=<myArtifactId> -Dversion=<myVersion> \
                         -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

Mise à jour: Il semble que install:install-file ignore le localRepositoryPath lors de l'utilisation de la version 2.2 du plug-in. Cependant, cela fonctionne avec la version 2.3 et ultérieure du plugin. Utilisez donc le nom complet du plugin pour spécifier la version:

mvn org.Apache.maven.plugins:maven-install-plugin:2.3.1:install-file \
                         -Dfile=<path-to-file> -DgroupId=<myGroup> \ 
                         -DartifactId=<myArtifactId> -Dversion=<myVersion> \
                         -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

documentation de maven-install-plugin

Enfin, déclarez-le comme n'importe quelle autre dépendance (mais sans la portée system):

<dependency>
  <groupId>your.group.id</groupId>
  <artifactId>3rdparty</artifactId>
  <version>X.Y.Z</version>
</dependency>

C’est à mon humble avis une meilleure solution que d’utiliser une étendue system car votre dépendance sera traitée comme un bon citoyen (par exemple, elle sera incluse dans une assemblée, etc.).

Maintenant, je dois mentionner que la "bonne façon" de traiter cette situation dans un environnement d'entreprise (ce n'est peut-être pas le cas ici) serait d'utiliser un référentiel d'entreprise.

332
Pascal Thivent

Utilisation de la portée system. ${basedir} est le répertoire de votre pom.

<dependency>
    <artifactId>..</artifactId>
    <groupId>..</groupId>
    <scope>system</scope>
    <systemPath>${basedir}/lib/dependency.jar</systemPath>
</dependency>

Cependant, il est conseillé d'installer votre fichier jar dans le référentiel et de ne pas l'envoyer au SCM. Après tout, c'est ce que maven tente de supprimer.

120
Bozho

Ceci est une autre méthode en plus de ma réponse précédente à Puis-je ajouter des fichiers JAR à maven 2 build classpath sans les installer?

Cela permettra de contourner la limite lors de l'utilisation de versions multi-modules, en particulier si le fichier JAR téléchargé est référencé dans des projets enfants en dehors du parent. Cela réduit également le travail d'installation en créant les fichiers POM et SHA1 dans le cadre de la construction. Cela permet également au fichier de résider n’importe où dans le projet sans fixer les noms ni suivre la structure du référentiel maven.

Ceci utilise le plugin maven-install. Pour que cela fonctionne, vous devez configurer un projet multi-module et disposer d'un nouveau projet représentant la version permettant d'installer les fichiers dans le référentiel local et de s'assurer que celui-ci est le premier.

Votre projet multi-module pom.xml ressemblerait à ceci:

<packaging>pom</packaging>
<modules>
<!-- The repository module must be first in order to ensure
     that the local repository is populated -->
    <module>repository</module>
    <module>... other modules ...</module>
</modules>

Le fichier repository/pom.xml contiendra ensuite les définitions permettant de charger les fichiers JAR faisant partie de votre projet. Vous trouverez ci-dessous des extraits du fichier pom.xml.

<artifactId>repository</artifactId>
<packaging>pom</packaging>

Le pom packaging empêche cela de faire des tests, de compiler ou de générer des fichiers jar. La viande du fichier pom.xml se trouve dans la section de construction où le plug-in maven-install-est utilisé.

<build>
    <plugins>
        <plugin>
            <groupId>org.Apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <executions>
                <execution>
                        <id>com.ibm.db2:db2jcc</id>
                        <phase>verify</phase>
                        <goals>
                            <goal>install-file</goal>
                        </goals>
                        <configuration>
                            <groupId>com.ibm.db2</groupId>
                            <artifactId>db2jcc</artifactId>
                            <version>9.0.0</version>
                            <packaging>jar</packaging>
                            <file>${basedir}/src/jars/db2jcc.jar</file>
                            <createChecksum>true</createChecksum>
                            <generatePom>true</generatePom>
                        </configuration>
                </execution>
                <execution>...</execution>
            </executions>
        </plugin>
    </plugins>
</build>

Pour installer plusieurs fichiers, ajoutez simplement plus d'exécutions.

27
Archimedes Trajano

J'ai déjà écrit sur un motif pour le faire.

Elle ressemble beaucoup à la solution proposée par Pascal, même si elle déplace toutes ces dépendances dans un module de référentiel dédié afin que vous n'ayez pas à la répéter partout où la dépendance est utilisée s'il s'agit d'une construction à plusieurs modules.

9
Brett Porter

Cela fonctionne pour moi: disons que j'ai cette dépendance

<dependency>
    <groupId>com.company.app</groupId>
    <artifactId>my-library</artifactId>
    <version>1.0</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/my-library.jar</systemPath>
</dependency>

Ensuite, ajoutez le chemin de classe pour votre dépendance système manuellement comme ceci

<Class-Path>libs/my-library-1.0.jar</Class-Path>

Configuration complète:

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        <archive>
            <manifestEntries>
                <Build-Jdk>${jdk.version}</Build-Jdk>
                <Implementation-Title>${project.name}</Implementation-Title>
                <Implementation-Version>${project.version}</Implementation-Version>
                <Specification-Title>${project.name} Library</Specification-Title>
                <Specification-Version>${project.version}</Specification-Version>
                <Class-Path>libs/my-library-1.0.jar</Class-Path>
            </manifestEntries>
            <manifest>
                <addClasspath>true</addClasspath>
                <mainClass>com.company.app.MainClass</mainClass>
                <classpathPrefix>libs/</classpathPrefix>
            </manifest>
        </archive>
    </configuration>
</plugin>
<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.5.1</version>
    <executions>
        <execution>
            <id>copy-dependencies</id>
            <phase>package</phase>
            <goals>
                <goal>copy-dependencies</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory}/libs/</outputDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>
8
RufusSC2

nous sommes passés à gradle et cela fonctionne beaucoup mieux en grade;). nous spécifions simplement un dossier dans lequel nous pouvons déposer des bocaux pour des situations temporaires comme celle-là. Nous avons toujours la plupart de nos pots définis dans la section typique de gestion de la dépendance (c'est-à-dire identique à celle de maven). Ceci est juste une dépendance de plus que nous définissons.

donc, fondamentalement, nous pouvons maintenant déposer n'importe quel fichier jar que nous voulons dans notre répertoire lib pour un test temporaire s'il ne s'agit pas d'un référentiel in maven.

4
Dean Hiller

En gros, ajoutez ceci au fichier pom.xml:

...

<repositories>
   <repository>
       <id>lib_id</id>
       <url>file://${project.basedir}/lib</url>
   </repository>
</repositories>

...

<dependencies>
  ...
  <dependency>
      <groupId>com.mylibrary</groupId>
      <artifactId>mylibraryname</artifactId>
      <version>1.0.0</version>
  </dependency>
  ...
</dependencies>
4
Fulgencio Jara

Un petit ajout à la solution publié par Pascal

Quand j'ai suivi cette route, j'ai eu une erreur dans maven lors de l'installation de jar ojdbc.

[INFO] --- maven-install-plugin:2.5.1:install-file (default-cli) @ validator ---
[INFO] pom.xml not found in ojdbc14.jar

Après avoir ajouté -DpomFile, le problème a été résolu.

$ mvn install:install-file -Dfile=./lib/ojdbc14.jar -DgroupId=ojdbc \
   -DartifactId=ojdbc -Dversion=14 -Dpackaging=jar -DlocalRepositoryPath=./repo \
   -DpomFile=~/.m2/repository/ojdbc/ojdbc/14/ojdbc-14.pom
2
veeseekay

Vous pouvez utiliser Eclipse pour générer un fichier Jar exécutable: Export/Runnable Jar

0
user1942990