Eu tenho este erro no eclipse helios:
Exceção ao executar linha de comando. Não é possível executar o programa "C: \ Arquivos de programas (x86) \ Java \ jre6 \ bin \ javaw.exe" (no diretório "C: \ Usuários \ motiver \ helios_workspace \ TimeTracker"): Erro CreateProcess = 206, O nome do arquivo ou extensão é demasiado longo
Pesquisei um pouco, mas a maioria dos problemas estava relacionada ao DataNucleus ao trabalhar no Google App Engine. Mas não estou usando nada remotamente relacionado ao Google App Engine. Estou fazendo um pequeno projeto com o Servlet 3.0 no JBOSS 6. Estou usando o Hibernate 4.1.2 para ORM e o RESTEasy para expor um serviço da web. Criei um arquivo util que tem um método main () que basicamente elimina e recria o esquema. Eu executo o método main () quando preciso de um banco de dados limpo para fins de teste. Funcionou bem no Tomcat 7, mas parou de funcionar quando mudei para o JBoss 6.
Qualquer sugestão ou solução seria muito apreciada.
C:\Program Files (x86)\Java\jre6\bin\javaw.exe
é longo ou o outroC:\Users\motiver\helios_workspace\TimeTracker
. Eu também estou tendo o mesmo problema.Respostas:
Não existe uma solução simples (como alguns cliques ou um comando simples) para esse problema.
Citando algumas respostas neste relatório de bug em Eclipse.org , estas são as soluções alternativas. Escolha aquele que for menos doloroso para você:
Atualização : depois de julho de 2014, há uma maneira melhor (graças à resposta de @Brad-Mace abaixo :
Se você criou seu próprio arquivo de construção em vez de usar
Project -> Generate Javadocs
, pode adicionaruseexternalfile="yes"
à tarefa Javadoc, que é projetada especificamente para resolver esse problema.fonte
-classpath
argumento foi gerado para conter todas as dependências. Então, algo como isto saiu:C:\Users\myself\.m2\repository\…;C:\Users\myself\.m2\repository\…[…tons more]
. Mover meu cache de repositório maven localD:\m2
fez o truque: Classpath encolheu paraD:\m2\…;D:\m2\…
- bingo! Lembre-se de definir olocalRepository
caminho em sua configuração maven.Se você criar seu próprio arquivo de construção em vez de usá-
Project -> Generate Javadocs
lo, poderá adicionaruseexternalfile="yes"
àjavadoc
tarefa, que é projetada especificamente para resolver esse problema.fonte
Eu enfrentei esse problema hoje e consegui resolvê-lo usando este plugin do Gradle
O url do github é este
SE você, como eu, não tem ideia do que é Gradle, mas precisa executar um back-end para fazer seu trabalho de front end, o que você precisa fazer é encontrar o arquivo build.gradle que está sendo chamado para iniciar seu servidor BE e adicioná-lo a o topo:
fonte
attributes["Main-Class"]
Respondendo minha própria pergunta aqui para que a solução não fique enterrada em comentários. Exportei o projeto como um jar executável de dentro do eclipse e fiz uma linha de comando "java -jar MyJar.jar" e funciona perfeitamente bem
fonte
Tente atualizar sua versão do Eclipse; o problema foi resolvido recentemente (12/03/2013). Verifique o relatório de bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=327193
fonte
Isso não é especificamente para o eclipse, mas a maneira que consegui contornar isso foi criando um link simbólico para o meu repositório maven e apontando para algo como "C: \ R". Em seguida, adicionei o seguinte ao meu arquivo settings.xml:
O caminho do repositório maven estava contribuindo para os problemas de comprimento na minha máquina Windows.
fonte
No intellij, há uma opção para 'encurtar a linha de comando', selecionar 'manifesto JAR' ou '@argFiles' resolveria o problema, basicamente, colocará o caminho de sua classe longo em um arquivo jar ou um arquivo temporário
fonte
A pergunta é antiga, mas ainda é válida. Eu me deparo com essa situação frequentemente sempre que um novo membro se junta à minha equipe ou um novo segmento de código é adicionado ao código existente. A solução simples que seguimos é "Reduzir o caminho de classe" movendo os diretórios para cima.
Como a pergunta mencionada, isso não é específico para eclipse. Eu também encontrei esse problema no IntelliJ Idea 14 e 2018.
Depois de uma longa pesquisa, descobri que a solução é definir o
em javc do arquivo de construção ant.
É assim que meu formiga build javac se parece agora. Para saber mais sobre o fork, consulte a documentação do ant.
fonte
No relatório de bug Bug 327193 é considerado corrigido, mas isso aconteceu comigo recentemente com o Eclipse Kepler 4.3.2.
Baixe o patch para Eclipse Juno ou mais recente:
https://bugs.eclipse.org/bugs/attachment.cgi?id=216593
fonte
Experimente isto:
fonte
Para resolver:
Se você estiver usando o Eclipse:
Mova o repositório .m2 para
c: \ Vá para Eclipse> Windows / Preferences / Maven / User Settings -> Crie seu próprio setting.xml com seu conteúdo:
Se você estiver usando IntelliJ: Vá para IntelliJ> clique com o botão direito do mouse em "pom.xml"> maven> crie "settings.xml"
com seu conteúdo:
fonte
Eu tenho o mesmo erro, ao invocar Maven.
A causa raiz do meu problema era
classpath
enorme. Atualizar o classpath corrigiu o problema.Existem várias maneiras de atualizar o grande caminho de classe, conforme mencionado aqui: Como definir um longo caminho de classe Java no Windows?
Como estou usando o Intellij, eles oferecem a opção de usar o arquivo de argumento que usei.
fonte
Updating the classpath
- como?Tente adicionar isso no
gradle version 4.10.x
arquivo build.gradle ( ) e verifique secom.xxx.MainClass
esta é a classe onde reside o seu método principal:A alteração acima deve resolver o problema, há outra maneira de usar o script
run.sh
abaixo para corrigir esse problema, mas será mais uma correção de linha de comando, não no IntelliJ para iniciargradle bootRun
.fonte
isso acontece devido ao DataNucleus às vezes sobrescrever os Argumentos com muitos caminhos.
Você deve sobrescrevê-los com este:
-enhancerName ASM -api JDO -pu MediaToGo
Espero te ajudar!
fonte
A resposta válida deste tópico foi a resposta certa para o meu caso especial. Especificar o caminho da pasta ORM para datanucleus certamente reduzirá a compilação do caminho java.
https://stackoverflow.com/a/1219427/1469481
fonte
Recebi o erro abaixo quando executo o ' ant deploy '
Corrigido executando ' ant clean ' antes dele.
fonte
Recebi o mesmo erro no Android Studio. Consegui resolver isso executando Build -> Clean Project no IDE.
fonte
Isso se deve ao seu longo nome de diretório de projeto, o que lhe dá um nome muito longo
CLASSPATH
. Ou você precisa reduzir os jars adicionados emCLASSPATH
(certifique-se de remover apenas os jars desnecessários) Ou a melhor maneira é reduzir o diretório do projeto e importar o projeto novamente. Isso reduzirá oCLASSPATH
. Funcionou para mimfonte
Eu tive o mesmo problema, mas estava usando o netbeans.
Eu encontrei uma solução, então estou compartilhando aqui porque não encontrei isso em nenhum lugar, então se você tiver esse problema no netbeans, tente isto:
(os nomes podem estar errados já que meu netbeans está em português) Clique com o botão direito do mouse no projeto> propriedades > construir> compilar> Desmarque executar compilação na VM externa.
fonte
Eu tenho o mesmo erro. Soluções experimentadas como limpeza, reconstrução, invalidateCache, reinicialização etc, mas nada funciona.
Acabei de criar uma nova pasta com um nome curto e copiei todos os arquivos (pasta do aplicativo, arquivos gradle, etc.) em uma nova pasta. Aplicativo aberto no Android Studio e está funcionando bem.
fonte
No meu caso, o erro estava aparecendo porque a versão java do sistema era diferente da versão java do intellijj / eclipse. O sistema e o usuário tinham versões diferentes do java. Se você compilar seu código usando uma versão e tentar executar usando uma versão diferente, ocorrerá um erro.
Para encurtar a história, certifique-se de que seu código seja compilado e executado pela mesma versão java.
fonte
Adicione abaixo ao seu arquivo Gradle:
plugins {`id" com.github.ManifestClasspath "versão" 0.1.0-RELEASE "
}
Veja https://plugins.gradle.org/plugin/com.github.ManifestClasspath
fonte
Para consertar esse erro abaixo, pesquisei bastante, não achei nenhuma boa solução, preparei esse script e está funcionando bem, pensado para compartilhar com o público e aproveitar para economizar tempo.
Se você estiver usando a ferramenta de compilação Gradle, o arquivo executável é colocado no diretório build / libs de seu aplicativo.
run.sh
-> crie este arquivo no diretório raiz do seu projeto e copie o script abaixo nele, vá para git bash e digite run.sh e digite. Espero que isto ajude!#!/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
Espero que isto ajude!!
fonte
Estou usando uma versão legada dos plug-ins Gradle e este plug in resolveu o problema para mim.
Uso (verifique a fonte para mais detalhes):
fonte
Em uma máquina Windows, existe uma limitação do nome do arquivo jar / comprimento do caminho na linha de comando, devido à qual você vê a mensagem de erro abaixo, tentei pesquisar muito, até tentei aplicar a solução acima, algum motivo, não funcionou, encontrei o snippet de trabalho do Gradle (gradle-4.10.2-all.zip)
Erro:
CreateProcess error=206, The filename or extension is too long
Use este
gradle.build
trecho de código abaixo para corrigir o problema acima no IntelliJ ou STS, ou eclipse qualquer coisa.Correção de código do Gradle:
fonte
Quantas pessoas tristes acima, existem muitos plug-ins para gradle executar um bypass neste problema como:
ou
Mas a melhor solução que encontrei foi matar o processo JVM e tudo está feito.
fonte