Discussion :

[EddyGiraudeau]

Bonsoir,

Je tente de générer un .jar qui contiendrait mes libraries (rien de bien sorcier jusque là).
Dans mon répertoire "dist" j'ai :
- mon .jar
- un répertorie "lib" qui contient les libraries

Cependant, si je copie/colle mon .jar ailleurs, plus rien ne fonctionne puisque les libraries ne sont pas incluses à l'intérieur.

J'espère être assez clair.

Contexte :
- Netbeans 8.0.2
- JavaFX project
- Java 8 update 60

Merci.

[EddyGiraudeau]

Petite précision, je ne peux pas utiliser Maven pour gérer mon projet. Je dois utiliser sapjco3.jar et SAP n'autorise pas le fait de renommer la dépendance.

J'avoue ne pas comprendre comment c'est possible que mes libraries ne soient pas incluses dans mon jar.

Je cherche encore...

[bouye]

Comme tu l'as remarqué tes dépendances sont situées dans le répertoire lib. D'ailleurs le champs Class-Path du manifeste de ton JAR principal doit les référencer texto. Donc si tu copies ailleurs ton JAR principal, il faut aussi copier le répertoire lib et tout son contenu avec.

Si tu veux vraiment un seul et unique JAR, je ne connais pas de solutions dans NetBeans (et n'ai jamais trop cherché de ce coté) mais il est assez facile de créer un script appelant la commande jar pour dezipper puis rezipper tout dans une unique archive. On peut aussi très aisément et rapidement se créer un petit programme Java utilisant l'API JAR (package java.util.jar) qui fait pareil. Évidement dans les deux cas, il faut penser a modifier correctement le nouveau manifeste (et non pas recopier betement celui du JAR principal précédent) et re-signer l'archive après si elle était signée lors de sa génération par NetBeans.

Il existe probablement qq part des outils deja prets a l'emploi qui font la meme chose.

[EddyGiraudeau]

Ok merci pour ta réponse.
Du coup je vais voir pour me tourner vers Launch4j. Sinon je déploierai le répertoire "lib" sur les quelques postes que je dois installer.
Les autres applications (qui ne contiennent pas sapjco3.jar) ne posent pas de problème car avec Maven les dépendances sont directement incluses dans le jar final.

Du coup, je remercie SAP pour leur super jar ;-)

Bonne soirée.

[bouye]

Mais du coup, avec Maven, elles sont incluses sous forme de JAR dans le JAR ou tout se retrouve a plat dans l'archive ? C'est pas une mauvaise idée en soit mais du coup ça casse probablement la signature numérique des JAR provenant de librairies tierces. C'est un peu comme si tu extrayais le contenu de DLLs signés présents sur ton système pour le mettre dans ton exe et ensuite tout re-signer la chose a ta sauce (alors qu'il me parait plus logique que la signature de la lib externe doive être celle de son éditeur). Et, si tout est a plat, cas de collision de noms de fichier, classes, ressources, fichiers de redéfinitions de classes pour le ServiceLoader, etc. : si tout est dans le même JAR, a la fin il n'en reste qu'un seul, pas forcement le bon.

[EddyGiraudeau]

Bonjour Bouye,

J'ai voulu vérifier avant de venir valider. Donc effectivement, en utilisant Maven, les dépendances sont stockées à plat dans le jar final. Quand tu parles de collision, cela signifie-t-il qu'une classe X qui se trouve dans un répertorie Y, peut entrer en collision avec une classe X (d'un autre jar) qui se trouve dans un répertoire Z ?

Personnellement je trouve ça très pratique mais je comprends tout à fait que ce n'est pas spécialement correct de faire sauter la signature de l'éditeur.

Bonne journée.

[bouye]

Non je pensais plutôt a une classe se trouvant dans un autre repertoire Y (pas Z), c'est-a-dire avec exactement le même chemin. Mais en fait c'est pas au niveau des classes (le ClassLoader prend la première version de la classe qu'il trouve sur le CLASSPATH) que ça doit être gênant mais plutôt au niveau des fichiers joints annexes (image, son, vidéo, fichier de config, fichier de redéfinition de classe pour le ServiceLoader*, etc.) puisque ceux-ci sont normalement résolus par le ClassLoader d'abord en fonction de leur fichier JAR source et ensuite sur le CLASSPATH (pas 100% sur ; il faudrait que je vérifie un de ces 4). Et donc de toute manière puisque tout est a plat, il ne plus y avoir du coup plusieurs fichiers avec le même nom.

*java.util.ServiceLoader permet de fournir une fabrique d'implementation concrète a des interface via des fichiers texte de redéfinitions (portant le nom complet de l'interface et contenant le nom de la classe concrète) qui sont placés dans le repertoire META-INF/services d'un fichier JAR.

Bon, ce n'est pas grave. C’était juste une question pour ma culture personnelle et si tu n'as jamais rencontré de soucis jusqu’à présent y q pas de raison que ça intervienne dans l’immédiat. Le plus gênant reste la perte des signatures numériques de l’éditeur des libs tierces, je trouve cependant.