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

J'ai un pom.xmlfichier qui définit les dépendances du framework d'application web que je veux utiliser, et je peux générer rapidement des projets de démarrage à partir de ce fichier. Cependant, parfois, je veux pom.xmlcréer un lien vers une bibliothèque tierce qui n'a pas encore de fichier défini, donc plutôt que de créer le pom.xmlfichier pour la bibliothèque tierce à la main et de l'installer, et d'ajouter la dépendance à ma pom.xml, je voudrais juste pour dire à Maven: "En plus de mes dépendances définies, incluez tous les pots qui s'y trouvent /libégalement."

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

Tous les conseils sur la façon de procéder sont grandement appréciés. En dehors de cela, s'il existe un moyen simple de pointer maven vers un /librépertoire et de créer facilement un pom.xmlavec tous les pots joints mappés sur une seule dépendance que je pourrais ensuite nommer / installer et lier à un seul coup suffirait également.

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.zMaven 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 repodossier, 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 pompour:

<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 libdossier 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.

Pour le code à jeter uniquement

définir le système scope == 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>

Remarque: les dépendances système ne sont pas copiées dans le fichier jar / war résultant
(voir Comment inclure les dépendances système dans war construit à l'aide de maven )

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

Par exemple, si vous avez un libsdossier dans la structure du projet

• Dans le libsdossier, vous devez créer une structure de répertoires comme:/groupId/artifactId/version/artifactId-version.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 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

Remarque: Lors de l'utilisation de l'étendue du système ( comme mentionné sur cette page ), Maven a besoin de chemins absolus.

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

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

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

Dans mon POM, j'avais une dépendance qui ne se trouve dans aucun référentiel Maven public

<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.1et 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 facultative, mais elle supprime un AVERTISSEMENT) et aide le gars suivant à 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 faire référence au référentiel local

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

Vous devez vraiment mettre en place un cadre 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 pervertie qui ne montrera pas le maven dans un état normal. Vous feriez mieux de suivre une approche comme celle-ci .

Voici comment ajouter ou installer 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é quelques groupId et artifactId par défaut car ils sont obligatoires :)

Le plugin d'installation Maven a une utilisation en ligne de commande pour installer un bocal dans le référentiel local, POM est facultatif mais vous devrez spécifier GroupId, ArtifactId, Version et Packaging (tous les éléments POM).

L'utilisation <scope>system</scope>est une idée terrible pour des raisons expliquées par d'autres, l'installation manuelle du fichier dans votre référentiel local rend la construction non reproductible, et l'utilisation <url>file://${project.basedir}/repo</url>n'est pas une bonne idée non plus car (1) qui peut ne pas être une fileURL bien formée (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 n'êtes pas disposé à télécharger l'artefact dans un référentiel public, la suggestion de Simeon d'un module d'assistance fait le travail. Mais il existe maintenant un moyen plus simple…

La recommandation

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

J'ai trouvé une autre façon de le faire, voir ici à partir d'un post Heroku

Pour résumer (désolé pour certains copier-coller)

• Créez un reporépertoire sous votre dossier racine:

votre projet
+ - pom.xml
+ - src
+ - repo

• Exécutez ceci pour installer le pot dans votre répertoire repo local

mvn deploy: deploy-file -Durl = file: /// path / to / yourproject / repo / -Dfile = mylib-1.0.jar -DgroupId = com.example -DartifactId = mylib -Dpackaging = jar -Dversion = 1.0

• Ajoutez ceci votre pom.xml:

<repositories>
    <!--other repositories if any-->
    <repository>
        <id>project.local</id>
        <name>project</name>
        <url>file:${project.basedir}/repo</url>
    </repository>
</repositories>


<dependency>
    <groupId>com.example</groupId>
    <artifactId>mylib</artifactId>
    <version>1.0</version>  
</dependency>

Après avoir longuement discuté avec les gars de CloudBees au sujet du conditionnement correct de ce type de JAR, ils ont fait une bonne proposition de solution intéressante:

Création d'un faux projet Maven qui attache un JAR préexistant comme artefact principal, s'exécutant dans l'installation POM appartenue: exécution du fichier d'installation. Voici un exemple d'un tel kinf de POM:

 <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <version>2.3.1</version>
            <executions>
                <execution>
                    <id>image-util-id</id>
                    <phase>install</phase>
                    <goals>
                        <goal>install-file</goal>
                    </goals>
                    <configuration>
                        <file>${basedir}/file-you-want-to-include.jar</file>
                        <groupId>${project.groupId}</groupId>
                        <artifactId>${project.artifactId}</artifactId>
                        <version>${project.version}</version>
                        <packaging>jar</packaging>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Mais pour le mettre en œuvre, la structure existante du projet doit être modifiée. Tout d'abord, vous devez avoir à l'esprit que pour chaque type de JAR, il devrait être créé différents faux projets Maven (module). Et il devrait être créé un projet Maven parent comprenant tous les sous-modules qui sont: tous les wrappers JAR et le projet principal existant. La structure pourrait être:

projet racine (il contient le fichier POM parent comprend tous les sous-modules avec l' élément XML du module ) (emballage POM)

Projet d'enveloppement JAR 1 Maven enfant (emballage POM)

Projet enfant Maven wrapper JAR 2 (emballage POM)

principal projet enfant Maven existant (emballage WAR, JAR, EAR ....)

Lorsque le parent s'exécute via mvn: install ou mvn: l'empaquetage est forcé et les sous-modules seront exécutés. Cela pourrait être considéré comme un inconvénient ici, car la structure du projet devrait être modifiée, mais offre une solution non statique à la fin

Ce qui me semble le plus simple, c'est simplement de configurer votre plugin-compilateur maven pour inclure vos pots personnalisés. Cet exemple charge tous les fichiers jar dans un répertoire lib.

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <includes>
                    <include>lib/*.jar</include>
                </includes>
            </configuration>
        </plugin>

Le problème systemPathest que les pots des dépendances ne seront pas distribués le long de vos artefacts en tant que dépendances transitives. Essayez ce que j'ai publié ici: est-il préférable de Mavenize vos fichiers jar de projet ou de les mettre dans WEB-INF / lib?

Déclarez ensuite les dépendances comme d'habitude.

Et veuillez lire la note de bas de page.

Une étrange solution que j'ai trouvée:

en utilisant Eclipse

• créer un projet java simple (non-maven)
• ajouter une classe principale
• ajouter tous les pots au chemin de classe
• exporter JAR exécutable (c'est important, car il n'y a pas d'autre moyen de le faire ici)
• sélectionnez Extraire les bibliothèques requises dans le fichier JAR généré
• décider des problèmes de licence
• tadammm ... installez le pot généré sur votre m2repo
• ajoutez cette dépendance unique à vos autres projets.

cheers, Balint

Si vous voulez une solution rapide et sale, vous pouvez faire ce qui suit (bien que je ne le recommande pas pour quoi que ce soit, sauf les projets de test, maven se plaindra longuement que ce n'est pas approprié).

Ajoutez une entrée de dépendance pour chaque fichier jar dont vous avez besoin, de préférence avec un script perl ou quelque chose de similaire et copiez / collez cela dans votre fichier pom.

#! /usr/bin/perl

foreach my $n (@ARGV) {

    $n=~s@.*/@@;

    print "<dependency>
    <groupId>local.dummy</groupId>
    <artifactId>$n</artifactId>
    <version>0.0.1</version>
    <scope>system</scope>
    <systemPath>\${project.basedir}/lib/$n</systemPath>
</dependency>
";

Une solution batch rapide et sale (basée sur la réponse d'Alex):

libs.bat

@ECHO OFF
FOR %%I IN (*.jar) DO (
echo ^<dependency^>
echo ^<groupId^>local.dummy^</groupId^>
echo ^<artifactId^>%%I^</artifactId^>
echo ^<version^>0.0.1^</version^>
echo ^<scope^>system^</scope^>
echo ^<systemPath^>${project.basedir}/lib/%%I^</systemPath^>
echo ^</dependency^>
)

Exécuter comme ceci: libs.bat > libs.txt. Ensuite, ouvrez libs.txtet copiez son contenu en tant que dépendances.

Dans mon cas, je n'avais besoin que des bibliothèques pour compiler mon code, et cette solution était la meilleure à cet effet.

Même si cela ne correspond pas exactement à votre problème, je vais le déposer ici. Mes exigences étaient:

1. Les fichiers JAR qui ne peuvent pas être trouvés dans un référentiel Maven en ligne doivent être dans le SVN.
2. Si un développeur ajoute une autre bibliothèque, les autres développeurs ne devraient pas être gênés de les installer manuellement.
3. L'IDE (NetBeans dans mon cas) devrait être en mesure de trouver les sources et les javadocs pour fournir la saisie semi-automatique et l'aide.

Parlons d'abord de (3): Le simple fait d'avoir les pots dans un dossier et de les fusionner dans le pot final ne fonctionnera pas ici, car l'IDE ne comprendra pas cela. Cela signifie que toutes les bibliothèques doivent être installées correctement. Cependant, je ne veux pas que tout le monde l'installe en utilisant "mvn install-file".

Dans mon projet, j'avais besoin de metawidget. Et c'est parti:

1. Créez un nouveau projet maven (nommez-le "shared-libs" ou quelque chose comme ça).
2. Téléchargez metawidget et extrayez le zip dans src / main / lib.
3. Le dossier doc / api contient les javadocs. Créez un zip du contenu (doc / api / api.zip).
4. Modifiez le pom comme ceci
5. Générez le projet et la bibliothèque sera installée.
6. Ajoutez la bibliothèque en tant que dépendance à votre projet ou (si vous avez ajouté la dépendance dans le projet de bibliothèques partagées) ajoutez des bibliothèques partagées en tant que dépendance pour obtenir toutes les bibliothèques à la fois.

Chaque fois que vous avez une nouvelle bibliothèque, ajoutez simplement une nouvelle exécution et dites à tout le monde de reconstruire le projet (vous pouvez améliorer ce processus avec les hiérarchies de projet).

Pour installer le pot tiers qui n'est pas dans le référentiel maven, utilisez maven-install-plugin.

Voici les étapes:

1. Téléchargez le fichier jar manuellement depuis la source (site web)
2. Créez un dossier et placez-y votre fichier jar
3. Exécutez la commande ci-dessous pour installer le pot tiers dans votre référentiel maven local

installation mvn: fichier d'installation -Dfile = -DgroupId = -DartifactId = -Dversion = -Dpackaging =

Ci-dessous, par exemple celui que je l'ai utilisé pour simonsite log4j

mvn install: install-file -Dfile = / Users / athanka / git / MyProject / repo / log4j-rolling-appender.jar -DgroupId = uk.org.simonsite -DartifactId = log4j-rolling-appender -Dversion = 20150607-2059 - Dpackaging = pot

4. Dans le pom.xml, incluez la dépendance comme ci-dessous

     <dependency> 
           <groupId>uk.org.simonsite</groupId>
           <artifactId>log4j-rolling-appender</artifactId>
           <version>20150607-2059</version> 
     </dependency>

5. Exécutez la commande mvn clean install pour créer votre emballage

Ci-dessous le lien de référence:

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

Pour ceux qui n'ont pas trouvé de bonne réponse ici, c'est ce que nous faisons pour obtenir un pot avec toutes les dépendances nécessaires. Cette réponse ( https://stackoverflow.com/a/7623805/1084306 ) mentionne l'utilisation du plugin Maven Assembly mais ne donne pas réellement d'exemple dans la réponse. Et si vous ne lisez pas jusqu'à la fin de la réponse (c'est assez long), vous risquez de le manquer. L'ajout de ce qui suit à votre pom.xml généreratarget/${PROJECT_NAME}-${VERSION}-jar-with-dependencies.jar

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>2.4.1</version>
            <configuration>
                <!-- get all project dependencies -->
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <!-- MainClass in mainfest make a executable jar -->
                <archive>
                  <manifest>
                    <mainClass>my.package.mainclass</mainClass>
                  </manifest>
                </archive>

            </configuration>
            <executions>
              <execution>
                <id>make-assembly</id>
                <!-- bind to the packaging phase -->
                <phase>package</phase> 
                <goals>
                    <goal>single</goal>
                </goals>
              </execution>
            </executions>
        </plugin>

J'ai fait allusion à du code python dans un commentaire à la réponse de @alex lehmann, alors je le poste ici.

def AddJars(jarList):
  s1 = ''
  for elem in jarList:
   s1+= """
     <dependency>
        <groupId>local.dummy</groupId>
        <artifactId>%s</artifactId>
        <version>0.0.1</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/manual_jars/%s</systemPath>
     </dependency>\n"""%(elem, elem)
  return s1

Cela ne répond pas à la façon de les ajouter à votre POM, et peut être une évidence, mais cela ajouterait-il simplement le répertoire lib à votre chemin de classe? Je sais que c'est ce que je fais quand j'ai besoin d'un pot externe que je ne veux pas ajouter à mes dépôts Maven.

J'espère que cela t'aides.

Ce qui fonctionne dans notre projet est ce qu'Archimedes Trajano a écrit, mais nous avions dans notre .m2 / settings.xml quelque chose comme ceci:

 <mirror>
  <id>nexus</id>
  <mirrorOf>*</mirrorOf>
  <url>http://url_to_our_repository</url>
 </mirror>

et le * devrait être changé en central. Donc, si sa réponse ne fonctionne pas pour vous, vous devriez vérifier vos paramètres.xml

Je voulais juste une solution rapide et sale ... Je ne pouvais pas exécuter le script de Nikita Volkov: erreur de syntaxe + cela nécessite un format strict pour les noms des pots.

J'ai fait ce script Perl qui fonctionne avec n'importe quel format pour les noms de fichiers jar, et il génère les dépendances dans un xml afin qu'il puisse être copié collé directement dans un pom.

Si vous souhaitez l'utiliser, assurez-vous de bien comprendre ce que fait le script, vous devrez peut-être modifier lib dossier et la valeur de groupIdou artifactId...

#!/usr/bin/perl

use strict;
use warnings;

open(my $fh, '>', 'dependencies.xml') or die "Could not open file 'dependencies.xml' $!";
foreach my $file (glob("lib/*.jar")) {
    print "$file\n";
    my $groupId = "my.mess";
    my $artifactId = "";
    my $version = "0.1-SNAPSHOT";
    if ($file =~ /\/([^\/]*?)(-([0-9v\._]*))?\.jar$/) {
        $artifactId = $1;
        if (defined($3)) {
            $version = $3;
        }
        `mvn install:install-file -Dfile=$file -DgroupId=$groupId -DartifactId=$artifactId -Dversion=$version -Dpackaging=jar`;
        print $fh "<dependency>\n\t<groupId>$groupId</groupId>\n\t<artifactId>$artifactId</artifactId>\n\t<version>$version</version>\n</dependency>\n";
        print " => $groupId:$artifactId:$version\n";
    } else {
        print "##### BEUH...\n";
    }
}
close $fh;

La solution pour l'approche scope = 'system' en Java:

public static void main(String[] args) {
        String filepath = "/Users/Downloads/lib/";
        try (Stream<Path> walk = Files.walk(Paths.get(filepath))) {

        List<String> result = walk.filter(Files::isRegularFile)
                .map(x -> x.toString()).collect(Collectors.toList());

                String indentation = "    ";
                for (String s : result) {
                    System.out.println(indentation + indentation + "<dependency>");
                    System.out.println(indentation + indentation + indentation + "<groupId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</groupId>");
                    System.out.println(indentation + indentation + indentation + "<artifactId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</artifactId>");
                    System.out.println(indentation + indentation + indentation + "<version>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</version>");
                    System.out.println(indentation + indentation + indentation + "<scope>system</scope>");
                    System.out.println(indentation + indentation + indentation + "<systemPath>" + s + "</systemPath>");
                    System.out.println(indentation + indentation + "</dependency>");
                }

    } catch (IOException e) {
        e.printStackTrace();
    }
}