Discussion :

[clem_alain]

Bonjour,

Jusqu'à présent je travaillais sur Helios, j'ai installé Indigo sur un Seven Pro, avec Jboss 6.1.0.Final.

Le lancement d'une simple application cliente référençant un EJB basique plante avec le message :

Exception occurred executing command line.
Cannot run program "C:\Program Files\Java\jre\bin\javaw.exe" (in directory "E:\Java\MyEclipse\MonAppliClient"): CreateProcess error=87, Nom de fichier ou extension trop long

J'ai pensé au problème du chemin avec un espace (Program Files) et j'ai donc réinstallé le jdk dans un dossier racine c:\java.
Cela ne change rien si ce n'est que le code est maintant

206 :
Exception occurred executing command line.
Cannot run program "C:\Java\jre\bin\javaw.exe" (in directory "E:\Java\MyEclipse\MonAppliClient"): CreateProcess error=206, Nom de fichier ou extension trop long

Evidemment, la même application fonctionnait et fonctionne encore sous Helios !

Si quelqu'un a une idée, je serais bien preneur.

Merci d'avance.

[Laurent.B]

Bonjour,

Ce genre d'erreur ne correspond pas à un problème d'espace dans le chemin mais indique plutôt que le chemin est trop long. Or, d'après ce que tu fournis, on est loin de la limite...

Ce problème est donc assez étrange à première vue.
Il n'y a rien qui te saute aux yeux dans ta configuration de lancement de ton application ?

La vue Error Log ne dit rien d'intéressant non plus ?

[Pedro4]

Je n'avais jamais eu cette erreur auparavant et suite à des ajouts de référence de sous-projets Eclipse, cette erreur apparaît.
En fait, tout est expliqué ici: https://bugs.eclipse.org/bugs/show_bug.cgi?id=327193
Du coup, en remplaçant les références à mes sous-projets par des références à des fichiers jars l'erreur disparaît.

[Laurent.B]

Et pour préciser la raison qui fait que cette erreur apparaît, en fait c'est un problème de limitation de Windows qui n'accepte pas l'exécution de commandes comportant plus de 8192 caractères.

Donc, lorsque l'on exécute un test sous Eclipse, avec un CLASSPATH trop gros, car faisant référence à de nombreux jars ou projets, alors on peut atteindre la limite.

Pour s'en sortir, la première solution est de réduire ce CLASSPATH autant que possible.

Ayant eu récemment la même erreur sur un projet s'appuyant sur Maven, j'ai fait en sorte, pour m'en sortir au moins temporairement, que mes projets Eclipse soient plus proches de la racine du disque.

Sur le bug pointé par Pedro4, il est indiqué effectivement les autres solutions possibles. Par contre, les développeurs Eclipse n'ont pas vraiment mis en priorité la mise en oeuvre d'un palliatif à ce problème, lequel reste il est vrai, majoritairement dû aux limitations de Windows...

[Gueritarish]

Salut,

Une solution utile aussi est de passer par le wildcard (partie "Understanding class path wildcards") dans le classpath. En général, les JARs d'une application sont "souvent" regroupé dans un même dossier. Ça peut être tout à fait utile.
Une autre approche (à tester) est de passer, dans Eclipse par des variables pour le classpath:
1. Ajout de la variable dans les variables accessibles pour le classpath:

2. Ajout de la variable dans le build path du projet:

3. On "étend" la variable pour pointer sur le jar:

4. On sélectionne le jar en question (ici javax.mail):

5. On a le jar dans le classpath (avec un chemin plus court):


Voilà, à+
Gueritarish

[Laurent.B]

Dans mon cas c'est plus compliqué je pense car le classpath est celui géré par Maven, en fonction du pom.xml. Donc, je ne vois pas trop comment intervenir simplement. De plus, c'est une application à base d'OSGi, donc les projets, bundles et jar nécessaires ne sont pas localisés à un seul endroit.

Ce qui est un peu pénible avec ce problème c'est qu'à aucun moment on ne peut voir facilement la commande complète exécutée... Du coup, le message d'erreur qui semble incohérent au premier abord, ne permet pas de comprendre facilement l'origine du problème.

A noter que lorsque l'on exécute un test unitaire en mode debug, ce problème a encore plus de chances de survenir, car on peut imaginer que la commande pour le mode debug est plus longue.

D'ailleurs, bien qu'ayant rapproché l'arborescence de mes projets à la racine du disque, j'ai constaté que l'exécution de mes tests unitaires ne fonctionnait toujours pas en mode debug. Donc j'ai de nouveau raccourci mon path, quasiment au plus court et là c'est passé.
J'ai une autre piste également pour pallier ce problème si jamais il resurvient, qui consiste à mettre mes projets dans le répertoire du workspace. Actuellement, mes projets sont ailleurs que dans le répertoire du workspace mais des collègues qui sont dans ce cas de figure n'ont pas de problème d'exécution des mêmes tests. Donc, je pense que ça doit jouer dans la longueur du classpath.