Erreur CreateProcess = 206, le nom de fichier ou l'extension est trop long lors de l'exécution de la méthode main ()


98

J'ai cette erreur dans l'hélios d'éclipse:

Une exception s'est produite lors de l'exécution de la ligne de commande. Impossible d'exécuter le programme "C: \ Program Files (x86) \ Java \ jre6 \ bin \ javaw.exe" (dans le répertoire "C: \ Users \ motiver \ helios_workspace \ TimeTracker"): erreur CreateProcess = 206, le nom de fichier ou l'extension est trop long

J'ai fait un peu de recherche, mais la plupart des problèmes étaient liés à DataNucleus lorsque je travaillais sur Google App Engine. Mais je n'utilise rien de lié à distance à Google App Engine. Je fais un petit projet avec Servlet 3.0 sur JBOSS 6. J'utilise Hibernate 4.1.2 pour ORM et RESTEasy pour exposer un service Web. J'ai créé un fichier util qui a une méthode main () qui supprime et recrée le schéma. J'exécute les methos main () lorsque j'ai besoin d'une base de données propre à des fins de test. Cela fonctionnait bien sur Tomcat 7, mais il a cessé de fonctionner lorsque je suis passé à JBoss 6.

Tout indice ou solution serait grandement apprécié.




Je veux comprendre si C:\Program Files (x86)\Java\jre6\bin\javaw.exec'est long ou l'autre C:\Users\motiver\helios_workspace\TimeTracker. J'ai aussi le même problème.
Siva R

Postérité: J'ai eu une situation similaire mais, avec une simple application d'entreprise déployée sur WLS et un client sur Eclipse. Ce que j'ai remarqué, c'est que le classpath était énorme car Eclipse, par défaut, incluait toute la bibliothèque WLS (tous les fichiers JAR). Je l'ai supprimé et ajouté, juste, weblogic.jar (seulement requis). Ensuite, cela a bien fonctionné. Donc, d'après mon observation, retirez simplement les pots inutiles.
lupchiazoem

Réponses:


49

Il n'y a pas de solution simple (comme en quelques clics ou une simple commande) à ce problème.

Citant certaines réponses de ce rapport de bogue dans Eclipse.org , voici les solutions de contournement. Choisissez celui qui vous fait le moins mal:

  • Réduisez le chemin des classes
  • Utilisez des répertoires au lieu de fichiers jar
  • Utilisez un fichier jar compressé qui contient tous les autres jars, utilisez la variable classpath à l'intérieur du fichier manifeste pour pointer vers les autres jars
  • Utilisez un chargeur de classe spécial qui lit le chemin de classe à partir d'un fichier de configuration
  • Essayez d'utiliser l'un des correctifs joints dans le document de rapport de bogue
  • Utilisez votre propre emballage, par exemple fourmi

Mise à jour : après juillet 2014, il existe un meilleur moyen (grâce à la réponse de @ Brad-Mace ci - dessous :

Si vous avez créé votre propre fichier de construction au lieu d'utiliser Project -> Generate Javadocs, vous pouvez ajouter useexternalfile="yes"à la tâche Javadoc, qui est spécialement conçue pour résoudre ce problème.


16
Comment IntelliJ n'aurait-il pas ce problème si c'est entièrement à cause de la longueur du chemin de classe utilisé lors du lancement de la JVM?
nitind

1
Cela pourrait être un problème d'éclipse uniquement, je suis capable d'exécuter l'application en utilisant maven.
surajz

3
@nitind "Dans IntelliJ IDEA, ils remplacent la classe principale par une classe générée. Elle contient le chemin d'accès aux classes codé en dur et le code pour lancer la classe principale d'origine." Tiré de bugs.eclipse.org/bugs/show_bug.cgi?id=327193#c8
Chobicus

2
En 2014, cette réponse est fausse et celle de @Brad Mace est correcte.
Bananeweizen

5
"Réduire le chemin de classe" est un bon indice, mais permettez-moi d'élaborer un peu sur ceci: dans mon cas, j'ai essayé de construire un projet maven, et l' -classpathargument a été généré pour contenir toutes les dépendances. Donc, quelque chose comme ça est sorti: C:\Users\myself\.m2\repository\…;C:\Users\myself\.m2\repository\…[…tons more]. Déplacer mon cache de dépôt maven local pour D:\m2faire l'affaire: Classpath s'est réduit à D:\m2\…;D:\m2\…- bingo! N'oubliez pas de définir le localRepositorychemin dans votre configuration maven.
ThomasR

18

Si vous créez votre propre fichier de construction au lieu d'utiliser, Project -> Generate Javadocsvous pouvez ajouter useexternalfile="yes"à la javadoctâche, qui est conçue spécifiquement pour résoudre ce problème.


1
Salut - comment ajouter exactement cela?
Prateek Narendra

@PrateekNarendra vous l'ajouteriez dans votre fichier de construction de fourmi (build.xml): ant.apache.org/manual/Tasks/javadoc.html
Brad Mace

17

J'ai rencontré ce problème aujourd'hui et j'ai pu le résoudre en utilisant ce plugin Gradle

C'est l' URL de github est-ce

Si, comme moi, vous n'avez aucune idée de ce qu'est Gradle mais que vous devez exécuter un backend pour faire votre travail frontal, ce que vous devez faire est de trouver le fichier build.gradle qui est appelé pour démarrer votre serveur BE et l'ajouter à haut:

plugins {
  id "ua.eshepelyuk.ManifestClasspath" version "1.0.0"
}

3
Maintenant, j'obtiens "Le nom de la classe principale n'a pas été configuré et il n'a pas pu être résolu", malgré avoir définiattributes["Main-Class"]
Anton3

1
J'ai essayé d'utiliser le plugin mais aucun effet. Le problème est toujours à venir. S'il vous plaît suggérer
amarnathpatel

8

Répondre à ma propre question ici pour que la solution ne soit pas enterrée dans les commentaires. J'ai exporté le projet en tant que jar exécutable depuis eclipse et j'ai fait une ligne de commande "java -jar MyJar.jar" et cela fonctionne parfaitement bien



5

Ce n'est pas spécifiquement pour eclipse, mais la façon dont j'ai contourné cela a été de créer un lien symbolique vers mon référentiel maven et de le pointer vers quelque chose comme "C: \ R". Ensuite, j'ai ajouté ce qui suit à mon fichier settings.xml:

<localRepository>C:\R</localRepository>

Le chemin du référentiel maven contribuait aux problèmes de longueur de ma machine Windows.


5

** entrez la description de l'image ici **

Dans intellij, il existe une option pour 'raccourcir la ligne de commande', sélectionnez 'JAR manifest' ou '@argFiles' résoudrait le problème, en gros, cela mettra votre long chemin de classe dans un fichier jar ou un fichier temporaire


4

La question est ancienne, mais toujours valable. Je rencontre souvent cette situation chaque fois qu'un nouveau membre rejoint mon équipe ou qu'un nouveau segment de code est ajouté au code existant. La solution de contournement simple que nous suivons est de "Réduire le chemin de classe" en remontant les répertoires.

Comme question mentionnée, ce n'est pas spécifique à l'éclipse. Je suis également tombé sur ce problème dans IntelliJ Idea 14 et 2018.

Après de longues recherches, j'ai trouvé que la solution était de régler le

fourchette = faux

dans javc du fichier de construction de fourmi.

<javac destdir="${build.dir}" fork="false" debug="on">
    <classpath .../>
    <src ... />
    <patternset ... />
</javac>

Voici à quoi ressemble mon javac de construction de fourmi maintenant. Pour en savoir plus sur fork, veuillez consulter la documentation ant.


C'est une réponse f ** king efficace que je trouve. Merci
huuthang

3

Dans le rapport de bogue Bug 327193, il est considéré comme corrigé, mais cela m'est arrivé récemment avec Eclipse Kepler 4.3.2.

Veuillez télécharger le correctif pour Eclipse Juno ou plus récent:

https://bugs.eclipse.org/bugs/attachment.cgi?id=216593

  1. Après le téléchargement, sauvegardez eclipse / plugins / org.eclipse.jdt.launching_3. *. Jar
  2. Copiez et collez les classes du correctif dans le JAR org.eclipse.jdt.launching (remplacez les fichiers existants).
  3. Redémarrez Eclipse.

Cela a fonctionné pour moi. Notez que l'application de ceci a supprimé mes installations Java JDK des JRE installés. J'ai dû les rajouter à nouveau. Une seule installation JRE a persisté.
Joetjah

Chose amusante, vous cherchez des réponses sur SO sur votre problème et l'une des réponses vient d'une personne avec laquelle vous avez étudié / travaillé :)
Michał Szkudlarek

1

Essaye ça:

java -jar -Dserver.port = 8080 build / libs / APP_NAME_HERE.jar


1

Pour le résoudre:

Si vous utilisez Eclipse:

Déplacer le référentiel .m2 vers

c: \ Allez dans Eclipse> Windows / Préférences / Maven / Paramètres utilisateur -> Créez votre propre setting.xml avec son contenu:

<settings>
  <localRepository>c:/.m2/repository</localRepository>
</settings>

Si vous utilisez IntelliJ: Allez dans IntelliJ> cliquez avec le bouton droit de la souris sur "pom.xml"> maven> créez "settings.xml"

avec son contenu:

<settings>
      xmlns="yourcontent"
      xmlns:xsi="yourcontent"
      xsi:schemaLocation="yourcontent.xsd">
  <localRepository>c:/.m2/repository</localRepository>
</settings>

1

J'ai eu la même erreur en invoquant Maven.

La cause première de mon problème était que classpathc'était très énorme. La mise à jour du classpath a résolu le problème.

Il existe plusieurs façons de mettre à jour le grand chemin de classe comme mentionné dans ceci: Comment définir un long chemin de classe Java dans Windows?

  1. Utiliser des caractères génériques
  2. Fichier d'argument
  3. Pot de cheminement

Puisque j'utilise Intellij, ils offrent la possibilité d'utiliser le fichier d'arguments que j'ai utilisé.


5
Updating the classpath- Comment?
Woland

1
Une réponse très vague. Comment diable avez-vous mis à jour classpath?
Testilla

Il existe plusieurs façons de mettre à jour le chemin de classe, par exemple le caractère générique.
Sandeep Jindal le

1

Essayez d'ajouter ceci dans le gradle version 4.10.xfichier build.gradle ( ) et vérifiez que c'est com.xxx.MainClassla classe où réside votre méthode principale:

plugins {
  id "ua.eshepelyuk.ManifestClasspath" version "1.0.0"
}
apply plugin: 'application'
application {
    mainClassName = "com.xxx.MainClass"
}

Le changement ci-dessus doit résoudre le problème, il existe un autre moyen d'utiliser le script run.shci-dessous pour résoudre ce problème, mais il s'agira davantage d'un correctif de ligne de commande, pas d'IntelliJ à lancer gradle bootRun.


0

cela se produit parce que DataNucleus écrase parfois les arguments avec de nombreux chemins.

Vous devez les écraser avec ceci:

-enhancerName ASM -api JDO -pu MediaToGo

J'espère vous aider!



0

J'ai l'erreur ci-dessous lorsque je lance ' ant deploy '

Cannot run program "C:\java\jdk1.8.0_45\bin\java.exe": CreateProcess error=206, The filename or extension is too long

Correction du problème en exécutant « ant clean » avant.


1
Et si j'utilise Android Studio? Je reçois également ce même problème
portfoliobuilder

J'utilise intelliJ
kn3l

0

J'ai eu la même erreur dans le studio Android. J'ai pu le résoudre en exécutant Build -> Clean Project dans l'EDI.


0

Cela est dû au long nom de répertoire de votre projet, ce qui vous donne un très long CLASSPATH. Soit vous devez réduire les fichiers JAR ajoutés à CLASSPATH(assurez-vous de supprimer uniquement les fichiers JAR inutiles), soit le meilleur moyen est de réduire le répertoire du projet et de réimporter le projet. Cela réduira le CLASSPATH. Cela a fonctionné pour moi.


0

J'ai eu le même problème, mais j'utilisais plutôt netbeans.
J'ai trouvé une solution, donc je partage ici parce que je n'ai trouvé cela nulle part, donc si vous avez ce problème sur netbeans, essayez ceci:
(les noms peuvent être désactivés puisque mon netbeans est en portugais) Cliquez avec le bouton droit sur projet> propriétés > build> compiling> Décochez exécuter la compilation sur une machine virtuelle externe.


0

J'ai eu la même erreur. Des solutions éprouvées comme le nettoyage, la reconstruction, invaliderCache, redémarrer, etc., mais rien ne fonctionne.

Je viens de créer un nouveau dossier avec un nom court et copié tous les fichiers (dossier d'application, fichiers gradle, etc.) dans un nouveau dossier. Application ouverte dans le studio Android et fonctionne bien.


0

Dans mon cas, l'erreur s'affichait parce que la version java du système était différente de la version java intellijj / eclipse. Le système et l'utilisateur avaient des versions Java différentes. Si vous compilez votre code en utilisant une version et essayez de l'exécuter en utilisant une version différente, une erreur se produira. La version java de l'utilisateur est la 1.8

#The system java version is 1.7.131
$ java -version
java version "1.7.0_131"

Bref, assurez-vous que votre code est compilé et exécuté par la même version java.



0

Pour corriger cette erreur ci-dessous, j'ai fait suffisamment de recherches, je n'ai pas obtenu de bonne solution, j'ai préparé ce script et il fonctionne bien, pensé à partager au public et à l'utiliser et à gagner du temps.

Erreur CreateProcess = 206, le nom de fichier ou l'extension est trop long

Si vous utilisez l'outil de génération Gradle et que le fichier exécutable est placé dans le répertoire build / libs de votre application. run.sh-> créez ce fichier dans le répertoire racine de votre projet, et copiez-y le script ci-dessous, puis allez dans git bash et tapez run.sh puis entrez. J'espère que cela t'aides!

#!/bin/bash dir_name=`pwd` if [ $# == 1 ] && [ $1 == "debug" ] then port=$RANDOM quit=0 echo "Finding free port for debugging" while [ "$quit" -ne 1 ]; do netstat -anp | grep $port >> /dev/null if [ $? -gt 0 ]; then quit=1 else port=`expr $port + 1` fi done echo "Starting in Debug Mode on "$port gradle clean bootjar jar_name="build/libs/"`ls -l ./build/libs/|grep jar|grep -v grep|awk '{print $NF}'` #java -jar -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=$port $jar_name elif [ $# == 1 ] && [ $1 == 'help' ] then echo "please use this commands" echo "------------------------" echo "Start in Debug Mode: sh run.sh debug" echo "Start in Run Mode: sh run.sh" echo "------------------------" else gradle clean bootjar word_count=`ls -l ./build/libs/|grep jar|grep -v grep|wc -w` jar_name=`ls -l ./build/libs/|grep jar|grep -v grep|awk '{print $NF}'`
jar_path=build/libs/$jar_name echo $jar_name #java -jar $jar_path fi

J'espère que cela t'aides!!


0

J'utilise la version héritée des plugins Gradle et ce plugin a résolu le problème pour moi.

Utilisation (vérifiez la source pour plus de détails):

Créer un extrait de script pour les plugins DSL pour Gradle 2.1 et versions ultérieures

plugins {
  id "com.github.ManifestClasspath" version "0.1.0-RELEASE"
}

Créer un extrait de script à utiliser dans les anciennes versions de Gradle ou lorsqu'une configuration dynamique est requise

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "gradle.plugin.com.github.viswaramamoorthy:gradle-util-plugins:0.1.0-RELEASE"
  }
}

apply plugin: "com.github.ManifestClasspath"

0

Dans une machine Windows, il y a une limitation du nom du fichier jar / de la longueur du chemin dans la ligne de commande, en raison de laquelle vous voyez le message d'erreur ci-dessous, j'ai beaucoup essayé de chercher, même j'ai essayé d'appliquer la solution ci-dessus, pour une raison quelconque, cela n'a pas fonctionné, j'ai trouvé l'extrait de code de travail pour Gradle (gradle-4.10.2-all.zip)

Erreur:

CreateProcess error=206, The filename or extension is too long

Utilisez cet gradle.buildextrait de code ci-dessous pour résoudre le problème ci-dessus dans IntelliJ ou STS, ou éclipser quoi que ce soit.

Correction du code Gradle:

apply plugin: 'application'

task pathingJar(type: Jar) {
    dependsOn configurations.runtime
    appendix = 'pathing'

    doFirst {
        manifest {
            attributes "Class-Path": configurations.runtimeClasspath.files.collect { it.getName() }.join(' ')
        }
    }
}

task copyToLib(type: Copy) {
    into "$buildDir/libs"
    from configurations.runtime
}

bootRun {
    systemProperties = System.properties
    //This below line is for if you have different profiles prod, dev etc...
    //systemProperty 'spring.profiles.active', 'dev'
    jvmArgs('-Djava.util.logging.config.file=none')
    mainClassName = "com.xxxx.Main"
    dependsOn pathingJar
    dependsOn copyToLib
    doFirst {
        classpath = files("$buildDir/classes/java/main", "$buildDir/resources/main", pathingJar.archivePath)
    }
}

0

Combien de personnes tristes ci-dessus, il y a beaucoup de plugins pour exécuter un by-pass dans ce problème comme:

plugins {
  id "ua.eshepelyuk.ManifestClasspath" version "1.0.0"
}

ou

plugins {
  id "com.github.ManifestClasspath" version "0.1.0-RELEASE"
}

Mais la meilleure solution que j'ai trouvée a été de tuer le processus JVM et tout est fait.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.