Discussion :

[GérardMartinelli]

Bonjour,

Il m'arrive un truc bizarre, lors de la création d'un jar. Je m'explique :

J'ai défini 5 projets différents, et lorsque je crée les JARs pour 4 d'entre-eux, tout se passe bien :

je clique bouton droit sur "create JAR", aux différentes questions je réponds "YES" en particulier pour remplacer l'ancien JAR.

Par contre sur l'un d'entre-eux, bien qu'on me demande également si je veux écraser l'ancienne version, (bien sûr je réponds oui), il ne remplace pas cette version et n'affiche aucun message d'erreur. Par contre si auparavant je supprime cette version, alors la création du nouveau jar est effective.

J'ai comparé le contenu des fichiers jardesc, et il n'y a aucune différence (à part le nom des classes). Comme je suis sous Windows 8.1, j 'ai aussi vérifié les propriétés des différents dossiers destinataires (en particulier l'onglet sécurités) et n'ai aucune différence quant aux autorisations d'accès.

Avez-vous des idées sur ce qui arrive ?

Merci d'avance

Gégé

[joel.drigo]

Salut,

Tu as regardé dans le fichier .log (dans le dossier .metadata) s'il y avait un message (ou plusieurs) d'erreur ?

[GérardMartinelli]

Oui j'ai regardé. J'ai d'abord arrêté Eclipse, supprimé le .log, puis relancé Eclipse et enfin recréé le jar (enfin j'ai essayé !!).

Les seuls messages que j'ai ,concernent le GIT que je n'ai pas installé. Voir ci-dessous

Quoi qu'il en soit, Merci pour ta réponse.

Gégé

!SESSION 2016-06-13 19:00:04.411 -----------------------------------------------
eclipse.buildId=4.4.2.M20150204-1700
java.version=1.8.0_31
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=fr_FR
Framework arguments: -product org.eclipse.epp.package.java.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.java.product

!ENTRY org.eclipse.egit.ui 2 0 2016-06-13 19:00:10.076
!MESSAGE Warning: EGit couldn't detect the installation path "gitPrefix" of native Git. Hence EGit can't respect system level
Git settings which might be configured in ${gitPrefix}/etc/gitconfig under the native Git installation directory.
The most important of these settings is core.autocrlf. Git for Windows by default sets this parameter to true in
this system level configuration. The Git installation location can be configured on the
Team > Git > Configuration preference page's 'System Settings' tab.
This warning can be switched off on the Team > Git > Confirmations and Warnings preference page.

!ENTRY org.eclipse.egit.ui 2 0 2016-06-13 19:00:10.077
!MESSAGE Warning: The environment variable HOME is not set. The following directory will be used to store the Git
user global configuration and to define the default location to store repositories: 'C:\Users\Gege'. If this is
not correct please set the HOME environment variable and restart Eclipse. Otherwise Git for Windows and
EGit might behave differently since they see different configuration options.
This warning can be switched off on the Team > Git > Confirmations and Warnings preference page.

[GérardMartinelli]

Comme je suis opiniâtre, j'ai fait d'autres tests : j'ai juste changé le nom du sous-répertoire dans lequel je veux créer le jar, et cette fois ça marche impeccablement.

J'ai pensé qu'il y a avait peut-être des restrictions sur les noms ?

Nom du Projet : BRIDGE
Nom du package : bridge
Nom du jar : bridge.jar
Nom du répertoire : D:\gege\java\Bridge ça ne marche pas
Nom du répertoire : D:\gege\java\Bridgex ça marche

J'ai donc changé de disque :

Nom du répertoire : F:\Test\Bridge ça marche

J'ai fait d'autres essais et obtenu des résultats surprenants :

J'ai déplacé la version de mon jar dans un autre dossier heure = 19h37.

Puis j'ai créé le jar dans mon dossier ---> heure = 19h43
J'ai attendu 3 minutes, et j'ai recréé le jar ---> heure = 19h43 au lieu de 19h46
J'ai alors copié mon ancien jar dans mon répertoire ---> heure = 19h37 (normal)

Puis j'ai recréé le jar dans mon dossier et Ô surprise le nouveau jar a bien été créé mais ---> heure = 19h43 alors qu'il est 19h48

Il semble qu'Eclipse ait conservé quelque part le jar créé à 19h43 et que c'est celui-ci qu'il remet dans le répertoire. Par contre si aucun précédent jar n'est dans le dossier alors il crée bien un nouveau fichier.

Donc je donne ma langue au chat.

Merci encore

[joel.drigo]

Je doute fortement qu'un jar soit conservé par Eclipse quelque part, mais ce n'est pas impossible... Qu'il y ait en revanche des mécanismes pour empêcher de regénérer un jar existant s'il n'y a aucune modification le justifiant, ça ne m'étonnerait pas.

Sinon, je pense à une raison possible pour qu'un jar existant ne soit pas recréé, c'est qu'il soit verrouillé par le système. Par exemple, lorsqu'il est utilisé par une application en cours d'exécution. En théorie, ça devrait tout de même provoquer un message d'erreur. Autre cas éventuel : le fichier jar est verrouillé par un autre processus (genre l'antivirus ou l'indexeur).

[GérardMartinelli]

Merci encore pour tes réponses. Pour ce qui est du verrouillage, j'ai re-booté au moins 10 fois, mais comme tu le dis, je devrais avoir un message d'erreur.
Par acquis de conscience sans trop y croire, j'ai regardé les dates des fichiers à l'intérieur de mon jar et Ô surprise (encore) j'ai vu que les classes avait été créées le 13/06/2016 à 20h21 alors que la date du fichier jar est 13/06/2016 à 19h43. (Voir les pièces jointes). Le plus surprenant c'est que cela n'arrive que pour ce package/projet et pour ce répertoire!!!
C'est pas beau tout cela ?

Enfin le principal que c'est que le jar contienne les dernières versions de mes classes.

Merci encore, si tu as d'autres idées n'hésite pas.

PS : Maintenant que j'ai cerné le problème j'ai été sur le Net pour savoir si il existait déjà et je suis tombé sur ce qui suit :


I have a strange problem with maven. I am using the filtering option to put some version information into a properties file. I then include that in the jar file, so that "Help/About" can tell me something useful. The problem I am having is that the version in the jar file is the previous version. So, if, for example I run a build at 0930, and another at 0940, then the version of the properties file in the jar generated at 0940 will have a build time of 0930. I am using the buildNumber plugin as well, but this issue is present whether or not I enable it.

What is even stranger is that when I run my build from within eclipse and run the program, the "old" file shows up on help/about, but then when I "Refresh" (F5) the eclipse project and re-run the program, I get the correct version. So could it be that maven is taking the eclipse version somehow? And why do you need to "refresh" in eclipse to get it to have the most up to date version.

[joel.drigo]

j'ai regardé les dates des fichiers à l'intérieur de mon jar et Ô surprise (encore) j'ai vu que les classes avait été créées le 13/06/2016 à 20h21 alors que la date du fichier jar est 13/06/2016 à 19h43. (Voir les pièces jointes).

Ceci est explicable en revanche : on peut ajouter des fichiers dans un jar sans le recréer. Ainsi 19h43 serait la date du création du fichier. Ensuite, chaque fichier inclus dedans a sa propre date de
dernière modification (ou de création). Ce qui serait logique : on ne supprime pas un jar existant pour le recréer, on le modifie.

Le texte que tu cites parle d'un autre problème : déjà ça concerne maven, et c'est au sujet d'un problème de rafraichîssement d'un fichier modifié de manière externe me semble-t-il (en effet, Eclipse a un cache et il faut forcer le refresh pour prendre en compte les mises à jour externes).

[GérardMartinelli]

J'ai enfin trouvé la raison de tout cela. C'est bête comme chou.

En fait l'explorateur de fichiers pour ce répertoire indique la date de création (Champs "Date") et non pas celle de modification (champ "Modifié le") alors que pour mes autres répertoires c'était l'inverse. En retirant ce champ de l'affichage et en ajoutant l'autre champ, tout est OK.

Bonne journée et merci pour ce débat intéressant.

[joel.drigo]

Je me demande si ce n'est pas un problème purement Windows ? Au moment de copier le fichier, le gestionnaire de fichiers Windows pourrait considérer que le jar (archive) n'est en fait qu'un répertoire et ne mettrait simplement à jour que les fichiers qu'il contient. C'est une hypothèse, mais je vais fouiller dans ce sens (je ne voudrais pas mourir idiot).

Je ne pense pas (je veux dire que j'en serais fort étonné) : Eclipse utilise des classes pour manipuler les fichiers (probablement JarOuputStream ou consort) : l'OS n'intervient pas. Les comportements automatisés d'un environnement ne sont pas des comportements de bas niveaux, d'os donc, mais de couches supérieures que Java ignore totalement (elles sont déjà trop sépcifique à chaque OS, mais aussi à chaque version d'OS). L'OS peut intervenir en revanche sur le traitement et le stockage des attributs (comme les dates) d'un fichier, l'OS ou un protocole pour des disques montés par exemple (par exemple, CICS ou SMB).

[GérardMartinelli]

J'ai enfin trouvé la raison de tout cela. C'est bête comme chou.

En fait l'explorateur de fichiers pour ce répertoire indique la date de création (Champs "Date") et non pas celle de modification (champ "Modifié le") alors que pour mes autres répertoires c'était l'inverse. En retirant ce champ de l'affichage et en ajoutant l'autre champ, tout est OK.

Bonne journée et merci pour ce débat intéressant et désolé pour t'avoir fait perdre du temps