Dépendance lib non Maven

Bonjour.

mon problème est le suivant
j'ai des libs qui ne sont pas géré par maven
je les utilise dans mes projets en mettant

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

<dependency> <groupId>de.sap</groupId> <artifactId>sapjco</artifactId> <version>3.0.0</version> <scope>system</scope> <systemPath>D:/project/libs/libsap//sapjco.jar</systemPath> </dependency> <dependency> <groupId>de.sap</groupId> <artifactId>sapidocjco</artifactId> <version>2.0.0</version> <scope>system</scope> <systemPath>D:/project/libs/libsap/sapidocjco.jar</systemPath> </dependency> <dependency> <groupId>de.sap</groupId> <artifactId>sapidoc</artifactId> <version>2.0.0</version> <scope>system</scope> <systemPath>D:/project/libs/libsap/sapidoc.jar</systemPath> </dependency>

---

j'obtiens un warning me disant que je devrais utiliser une variable.
ça tombe plutôt bien vu que mes projets vont êtres utilisés et compilés sur windows comme sous Unix.
j'ai donc définit dans le settings.xml de tous les développeurs et toutes les plateformes une propriété lib.sap qui pointe sur le dossier où ce trouve la lib.
et mes pom ressemblent donc à

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<dependency> <groupId>de.sap</groupId> <artifactId>sapidoc3</artifactId> <version>3.0.0</version> <scope>system</scope> <systemPath>${lib.sap}/sapidoc3.jar</systemPath> </dependency> <dependency> <groupId>de.sap</groupId> <artifactId>sapjco3</artifactId> <version>3.0.0</version> <scope>system</scope> <systemPath>${lib.sap}/sapjco3.jar</systemPath> </dependency> <dependency> <groupId>de.sap</groupId> <artifactId>sapjco3.dll</artifactId> <version>3.0.0</version> <scope>system</scope> <type>dll</type> <systemPath>${lib.sap}/sapjco3.dll</systemPath> </dependency>

---

mais du coup j'ai des messages me disant que le chemin systemPath devrait être absolut mais qu'il vaut ${lib.sap}la propriété lib.sap est pourtant sur toutes les machine un chemin absolut.

Que faire ???

Merci
A+JYT

Bonjour,

Une dépendance en scope system est à proscrire absolument !
Le plus simple, c'est d'installer les JAR dans le repository (local, donc sur la machine du développeur, ou mieux encore sur le repository d'entreprise si vous en avez un). Le fait que la dépendance soit "non mavenisée" n'est pas un problème. La commande suivante permettra de générer un pom basique :

Code:

---

1 2	mvn install:install-file -Dfile=sapjco.jar -DgroupId=de.sap -DartifactId=sapjco -Dversion=3.0.0 -Dpackaging=jar -DgeneratePom=true mvn install:install-file -Dfile=sapidocjco.jar -DgroupId=de.sap -DartifactId=sapidocjco -Dversion=2.0.0 -Dpackaging=jar -DgeneratePom=true

---

Une fois ces JAR déployés en local (ou dans le repository d'entreprise), il te suffira de les déclarer comme dépendances "normales".

Bonjour

Je n'ai jamais réussi à faire fonctionner JCO (http://www.sap.com/index.epx)
en générant un POM
JCO comporte plusieurs JAR des dll et so
lorsque je les mets sous maven sur mon nexus en générant des pom indépendant je ne parviens pas à exécuter ni à compiler mes dev

pour le moment la seul solution que j'ai trouvé est d'en passer par le scope system

j'ai cherché à savoir si je pouvais faire un pom de plusieurs jars so et dll mais ça ne marche pas non plus.

Merci
A+JYT

Je crois comprendre le problème: le connecteur java JCO utilise le nom en dur (i.e. sans version) pour la dll,so et autres jnilib :cry:

Une idée :

-1- inclure la librairies native dans le jar que tu peux mettre dans Nexus
Ensuite dans ton POM
-2- décompresser le jar; et, copier les librairies dans l'appli
-> possible utilisation de maven-dependency-plugin (phase prepare-package / goal unpack)
-3- finaliser le packaging

Mais bon, c'est assez lourdingue voire crad.... il doit bien avoir une meilleure solution.

a+
Philippe

Mettre les jar dans le repository maven et les dll / so dans les répertoires système de l'OS ne serait pas une solution?

J'ai une fois travaillé avec une librairie native sur laquelle je n'avais pas le controle, et c'était la supposition de base "la librairie est installée conformément aux recommendation du fournisseurs sur toute machine voulant exécuter le code". Donc on a tappé le jar dans maven (pour les dépendances) et on laissait à la responsabilité du gestionnaire de a machine l'installation des DLLS

Sinon, je craint qu'il faille vivre avec le warning :mouarf:

merci

le problème est que visiblement sapjco3.jar cherche le jar sapidoc3.jar et la lib native ....
donc si on mets dans un pom on a sapjco-3.0.0 et pas sap3 idem pour les autres.

on est donc partit sur l'idée que chacun est responsable de l'installation sur sa machine.

mais pour que le tout compile et que karaf retrouve ses petit il faut dans les bundles ajouter une dépendance vers les lib
d'où l'utilisation du scope system

j'imagine que si ce scope existe il doit bien y avoir une façon de le gérer proprement.

définir une variable sur chaque machine qui indique où trouver la lib nous paraissait la bonne solution.
c'est en tout cas la seul qui fonctionne à notre connaissance.
mais nous avons un invalid transitive dépendance qui traîné un peut partout

A+JYT

Comme on en a discuté l'an dernier le scope system devrait être réservé aux dépendances de la JDK comme tools.jar ! Mais celà n'explique pas ton résultat. sauf, que:

Depuis maven3 les properties sont dépréciées d'ailleurs de mémoire (à vérifier) pour y accéder il fallait faire ${settings.TOTO} et non pas ${TOTO} pour y accéder. Tu peux tjrs utiliser une variable d'environnement ${env.TOTO} ou une variable projet que tu peux définir entre les balises <projet><properties></properties></projet>.

Ou utiliser une solution crad de contournement.
a+
Philippe

Salut.
${settings.saplib} si j'ai défini saplib dans le fichier settings ?
Il y a une doc sur le sujet ?

Je vais tester ça demain
Merci
A+JYT

${settings.XXX} n'est pas reconnu par maven3

en fait ${settings.offline} par exemple récupère le contenu du tag <offline></offline> contenu dans <settings></<settings>
voila ce que j'ai trouvé dans la doc

Citation:

---

Envoyé par Maven

systemPath:
is used only if the the dependency scope is system. Otherwise, the build will fail if this element is set. The path must be absolute, so it is recommended to use a property to specify the machine-specific path (more on properties below), such as ${java.home}/lib. Since it is assumed that system scope dependencies are installed a priori, Maven will not check the repositories for the project, but instead checks to ensure that the file exists. If not, Maven will fail the build and suggest that you download and install it manually.

---

j'ai cherché dans une autre direction.
j'ai un projet B qui dépend du projet A qui lui dépend des lib en scope system

dans le projet B j'ai mis les dépendances vers lib system avec l'attribut optionnal
dans le projet A j'ai mis une dépendance vers le projet B avec exclusion des lib system
dans le projet A j'ai ajouté une dépendance directe vers les lib system

mon idée était qu'en les excluant et les mettant optionnelle je n'aurais plus de dépendance transitives donc plus de problème.
mais ça ne change rien. je effectivement que je n'ai plus de dépendance transitives mais j'ai toujours le même message.

A+JYT

Donc, c'est pire que dépréciées pour les properties utilisateurs :(

Les variables projets et/ou environnement ne peuvent-elles pas te donner une solutions ?

Avec ton test (exclusion/optional), celà ne m'étonne pas que tu es le même message.
La limitation, dans le scope system, sur la transitivité se limite à ces dépendances systèmes... C'est logique !

Ne peux-tu pas vivre avec le warning ?

Si non, il faut trouver une solution pour embarquer la partie native...
L'idée reste de conserver ta dépendance jar/natif hors Nexus tout en étant dans nexus: l'écriture d'un plugin maven pour SAP est peut-être la solution (hors solution de leurre proposée plus haut... i.e. jar englobant à décompresser)... As-tu cherché de ce côté ?

Cdlt,
Philippe