Eviter la recopie des fichiers .jar dans les répertoires dist/lib

**JiPe38** · 05/10/2017, 10h01

Bonjour

J'ai un souci. Une application décomposée en plusieurs projets / packages. A la base, par exemple, le projet "utilitaires". Au dessus, des projets p1, p2, etc.
Je fais un clean/build du projet "utilitaires" et il me crée dans ce projet un répertoire "dist" où il met le fichier "utilitaires.jar". Jusqu'ici OK.

Maintenant je fais un clean/build du projet p1, et dans le menu "run/set_project_configuration/customize", à l'onglet "lib", je déclare une librairie (ou bien un jar/folder) pointant sur mon fichier "utilitaires.jar". Je constate qu'au build il me crée un répertoire "lib" dans le répertoire "dist" du projet p1 et y recopie le fichier "utilitaires.jar".

C'est une source d'embrouilles, car si plus tard je refais le build du projet "utilitaires", il ne recopie pas son fichier jar dans les projets p1, p2, etc, et je me retrouve avec des erreurs dues à plusieurs versions du "utilitaires.jar" dans les divers projets, non compatibles avec le nouveau "utilitaires.jar" dans le répertoire "dist" du projet "utilitaires".

Comment faire pour que la désignation d'un "jar-folder" au "customize" du "run", travaille par référence et non par recopie du .jar ?

**tchize_** · 05/10/2017, 23h00

tu as essayé en faisant de projet type maven? Il ne devrait pas y avoir de recopie dans ceux là, puisque c'est maven qui centralise les binaires.

**JiPe38** · 06/10/2017, 12h37

Petit projet test avec Maven... oups, il importe je ne sais quel "repositery index" pendant une heure ! J'espérais un peu qu'avec Maven je pourrais faire des "nested packages", pour structurer mes projets, mais non : des packages tels que test1 et test1.sousTestA sont vus en mode "flat" dans la hiérarchie du projet. Peut être que c'est une contrainte java tout simplement.

Donc en admettant que je fasse un seul projet au lieu de cinq actuellement, et que j'utilise des packages avec une (fausse) hiérarchie type test1 et test1.sousTestA, je n'aurai alors qu'un seul .jar, ou même pas de .jar du tout dans la phase développement. En final, une fois le projet terminé et opérationnel, je pourrai le redécouper en plusieurs projets pour pouvoir distribuer mes fonctions sous forme de modules avec les .jar. Tous le même numéro de version, donc si l'un évolue, je les fais tous évoluer.

J'hésite : basculer sous Maven, avec le temps d'apprentissage nécessaire, ou employer l'approche naïve comme décrit ci-dessus. Retour d'expérience ?

**tchize_** · 06/10/2017, 22h29

Envoyé par JiPe38

Petit projet test avec Maven... oups, il importe je ne sais quel "repositery index" pendant une heure ! J'espérais un peu qu'avec Maven je pourrais faire des "nested packages", pour structurer mes projets, mais non : des packages tels que test1 et test1.sousTestA sont vus en mode "flat" dans la hiérarchie du projet. Peut être que c'est une contrainte java tout simplement.

L'index, c'est juste netbeans qui veut être plus catholique que le pape, ce n'est en général pas nécessaire, sauf si tu veux faire de l'autocompletion quand tu rajoutes des dépendances (genre savoir que apache commons dispose de 15 versions différentes nomérotées 1.0, 1.1, 1.2, 1.2.1, 1.2.3). Tu peux normalement le désactiver dans les options. C'est le même problème sur eclipse, l'index met 1h à télécharger. Le serveur où il est hébergé le livrant à 5K/s.

Pour cette histoire de flat, je ne sais pas trop de quoi tu parles. Si tu parles de la présentation des packages dans un projet, c'est une option de netbeans, rien à voir avec java ou maven. Maven supporte très bien la hierarchisation des projets en combinant les dépendances (qui a besoin de quoi) et les modules (raccourcis pour builder plein de trucs d'un coup). La manière dont netbeans présente ça importe peu. Eclipse par exemple présent chaque projet côte à côte car il n'a aucune notion de netsted project. Ca ne l'empêche pas de savoir qu'il y a des dépendances entre les projet et de gérer correctement les classpaths entre les projets.

http://books.sonatype.com/mvnex-book...ltimodule.html

Envoyé par JiPe38

Retour d'expérience ?

Maven s'apprend très vite, en quelque heures pour les opérations de base (build, dépendances, commandes). Ce qui prends du temps ce sont les trucs un peu plus complexe, genre quand il faut faire dialoguer 2 plugins entre eux alors qu'ils sont pas fait pour, ou quand il faut gérer le legacy.

Maven ne t'oblige pas à release tous tes modules dans la même version (même si c'est plus pratique)

**JiPe38** · 07/10/2017, 15h18

Lecture du fichier tuto Maven proposé... remontée à la racine du tuto, oups... un week end en perspective ! Parcouru en diagonale : effectivement Maven semble intéressant.

Pour l'instant, j'ai trouvé une solution provisoire. Mes ennuis venaient du fait que j'avais une dépendance croisée : le projet p1 dépendait de p2 et p2 dépendait de p1. En fait, la logique était de fusionner ces deux projets. Une fois fait, plus de souci... pour l'instant.

Mais je retiens Maven pour une phase ultérieure du développement et du déploiement, surtout que j'envisage de porter sur un serveur web, alors...
Merci pour le coup de main.