Avoir un pot tiers inclus dans le pot ombré Maven sans l’append au repository local

J’ai déjà trouvé une réponse sur Stack Overflow pour inclure un fichier JAR tiers dans un projet sans l’installer dans un “référentiel local”:

Puis-je append des fichiers jars à maven 2 build classpath sans les installer?

Mais lorsque j’utilise le plug-in Maven Shade pour créer un fichier JAR qui inclut également toutes les dépendances du projet, le fichier JAR tiers n’est pas inclus automatiquement.

Comment puis-je faire en sorte que Maven Shade Plugin ajoute un tel fichier JAR tiers au fichier JAR ombré?

Selon la réponse obtenue, je l’ai fait fonctionner. Ce que j’ai fait a été d’append cet extrait au début de mon fichier pom.xml:

  repo file://${basedir}/repo

Puis ajouté une dépendance pour mon projet, également à pom.xml:

   dummy dummy 0.0.0 comstack

Et puis couru une ligne de commande pour append un paquet à ‘repo’:

 mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file -Dfile=.jar -DgroupId=dummy -DartifactId=dummy -Dversion=0.0.0 -Dpackaging=jar -DlocalRepositoryPath=`pwd`/repo/

(Je ne sais pas si le chemin du repo doit être un chemin complet, mais je ne voulais pas prendre de risques.)

Le contenu du sous-répertoire repo est maintenant:

 repo/dummy/dummy/0.0.0/dummy-0.0.0.jar repo/dummy/dummy/0.0.0/dummy-0.0.0.pom repo/dummy/dummy/maven-metadata-local.xml

Maintenant, je peux vérifier cela dans le contrôle de version et ne pas avoir de dépendances locales ou distantes.

Toutefois, lorsque j’utilise le plug-in Maven Shade pour créer un fichier JAR incluant également toutes les dépendances du projet, le fichier JAR tiers n’est pas inclus automatiquement.

Oui, car les dépendances étendues du system sont supposées être toujours présentes (c’est exactement ce que concerne la scope du system ), elles ne seront donc pas incluses. En fait, les gens ne comprennent pas ce que sont les dépendances de la scope du system , ils continuent à en abuser (oui, il s’agit d’abus), puis à obtenir des effets secondaires et à se demander pourquoi.

J’ai déjà écrit beaucoup , beaucoup , beaucoup de fois à ce sujet ici sur SO et dans 99% des cas, les dépendances étendues au system devraient être évitées. Et je vais répéter ce que le mini-guide Dependency Scopes dit encore une fois:

system : cette dépendance est requirejse dans certaines phases du cycle de vie de votre projet, mais est spécifique au système. L’utilisation de cette scope est déconseillée: ceci est considéré comme un type de fonctionnalité “avancée” et ne devrait être utilisé que lorsque vous comprenez vraiment toutes les ramifications de son utilisation, ce qui peut être extrêmement difficile, voire impossible à quantifier. Cette scope par définition rend votre build non portable. Cela peut être nécessaire dans certains cas de bord. La scope du système inclut l’élément qui pointe vers l’emplacement physique de cette dépendance sur la machine locale. Il est donc utilisé pour faire référence à un artefact supposé être présent sur la machine locale donnée et non dans un référentiel; et dont le chemin peut varier d’une machine à l’autre. L’élément systemPath peut faire référence à des variables d’environnement dans son chemin: ${JAVA_HOME} par exemple.

Donc, au lieu d’utiliser la scope du system , soit:

Ajoutez vos bibliothèques à votre référentiel local via install:install-file . C’est un moyen rapide et sale de faire fonctionner les choses, cela peut être une option si vous êtes seul, mais cela rend votre construction non portable.
Installez et exécutez un “référentiel d’entreprise” tel que Nexus, Archiva ou Artifactory et ajoutez vos bibliothèques via deploy:deploy-file . C’est le scénario idéal .
Configurez un référentiel basé sur fichier comme décrit dans la réponse précédente et placez vos bibliothèques dans ce répertoire. C’est le meilleur compromis si vous ne disposez pas d’un référentiel d’entreprise mais que vous devez travailler en équipe et ne pas sacrifier la portabilité.

S’il vous plaît, arrêtez d’utiliser l’étendue du system .

Le plugin Maven addjars résout ce problème – voir

http://code.google.com/p/addjars-maven-plugin/wiki/UsagePage

Utilisé pour inclure ma lib avec tous les jars. c’est à dire:

    ${project.basedir}  lib/*.jar      org.apache.maven.plugins maven-shade-plugin 2.3  false    package  shade