Discussion :

[gronono]

Bonjour,

Je m'expose mon probleme :

Soit une appli Java qui utilise par exemple l'API common-collections (de Jakarta) en version 1.2
Si j'ai une deuxième appli qui utilise aussi common-collections, j'aimerais savoir si je peux remplacer le JAR utiliser par cette appli 2 par le plus récent des 2 Jars.

J'ai beau cherché mais rien me garantie
- qu'il y a une compatibilé ascendante entre les deux versions
- que le fichier le plus récent est celui qui contient la version la plus récente

La question est :
Comment centralier les fichiers JAR des différentes applications afin de maintenir les différentes API utilisés ?

[g_rare]

J'ai beau cherché mais rien me garantie
- qu'il y a une compatibilé ascendante entre les deux versions
- que le fichier le plus récent est celui qui contient la version la plus récente

C'est à toi de vérifier dans le "changelog" des APIs utilisées (voir le n° de version plutôt que la date ; on sait jamais) !

La question est :
Comment centralier les fichiers JAR des différentes applications afin de maintenir les différentes API utilisés ?

En général : on mets les JARs mutualisés de plusieurs applications dans un répertoire partagé, et même (mieux?) dans JRE>>LIB>>EXT ...

[gronono]

C'est à toi de vérifier dans le "changelog" des APIs utilisées (voir le n° de version plutôt que la date ; on sait jamais) !

Oui mais lorsque l'on a deux fichiers common-collections.jar et qu'ils ne contiennent pas exatement la même chose, comment faire pour déterminer la version ?

En général : on mets les JARs mutualisés de plusieurs applications dans un répertoire partagé, et même (mieux?) dans JRE>>LIB>>EXT ...

Justement, je mets lequel ?

[sinok]

EN général tu as le numéro de version qui est indiqué dans le fichier manifest du jar à l'attribut Specification-Version

[gronono]

EN général tu as le numéro de version qui est indiqué dans le fichier manifest du jar à l'attribut Specification-Version

Mais pas toujours.

En conclusion, je pense que si on ne fait pas un suivi des versions dès le commencent de l'appli, on est foutu.

merci quand même de vos réponses.

[g_rare]

En conclusion, je pense que si on ne fait pas un suivi des versions dès le commencent de l'appli, on est foutu.

C'est pour ça qu'on peut préconiser de mettre le numéro de version dans le nom du fichier (style "common-collections-3.2.jar") ; tu peux aussi repérer une modification de classe qui n'existe que dans la dernière version et vérifier si elle existe dans ton JAR (et ainsi de suite en arrière jusqu'à retrouver de quelle version est ton archive)...