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

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é.

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.

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.

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"
}

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

Essayez de mettre à jour votre version d'Eclipse, le problème a été résolu récemment (12/03/2013). Consultez le rapport de bogue https://bugs.eclipse.org/bugs/show_bug.cgi?id=327193

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.

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

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.

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.

Essaye ça:

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

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>

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é.

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.

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!

Une réponse valide de ce fil était la bonne réponse pour mon cas particulier. Spécifier le chemin du dossier ORM pour datanucleus réduit certainement le chemin de compilation java.

https://stackoverflow.com/a/1219427/1469481

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.

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.

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.

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.

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.

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.

#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.

Ajoutez ci-dessous à votre fichier gradle:

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

Voir https://plugins.gradle.org/plugin/com.github.ManifestClasspath

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!!

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"

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)
    }
}

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.