2013-02-06 17 views
5

Mam problem, gdy próbuję uruchomić klasę testową JUnit w środowisku Eclipse.Błąd 206 występuje w teście JUnit w Eclipse

Wystąpił wyjątek podczas wykonywania wiersza polecenia. Nie można uruchomić programu "C: \ Program Files \ Java \ jre7 \ bin \ javaw.exe" (w katalogu "C: \ Users \ User \ Documents \ Projects \ MyProject"): CreateProcess error = 206, Nazwa pliku lub rozszerzenie jest zbyt długo

Po otrzymaniu tego błędu zacząłem szukać sposobu rozwiązania problemu ... Jednak teraz wygenerowałem plik MANIFEST zawierający wszystkie słoiki, które potrzebuję, ale nie wiem, jak przekazać nowy plik manifestu do projektu, a także co zrobić ze słoikami w mojej bibliotece?

Z góry dziękuję!

EDIT:

mam klasę SimpleTest i TestRunner klasę

public class SimpleTest { 

    @Test 
     public void testAssertions() { 

      String str1 = new String ("abc"); 
      String str2 = new String ("abc"); 

      assertEquals(str1, str2);  
    } 
    } 

package com.epb.junit; 

import org.junit.runner.JUnitCore; 
import org.junit.runner.Result; 
import org.junit.runner.notification.Failure; 

public class TestRunner { 
    public static void main(String[] args) { 
     Result result = JUnitCore.runClasses(SimpleTest.class); 
     for (Failure failure : result.getFailures()) { 
     System.out.println(failure.toString()); 
     } 
     System.out.println(result.wasSuccessful()); 
    } 
} 

nic ciekawego tutaj, po prostu trzeba wiedzieć jak spakować wszystkie moje pliki JAR, które używam, bo są zbyt wiele ... Zrobiłem plik manifestu z wszystkimi, ale nie wiem jak przekazać go zamiast plików JAR.

P.S Używam klasy testowej z opcją Eclipse -> Uruchom jako -> JUnit. Po wystąpieniu błędu utworzyłem tę klasę TestRunner i używam jej jako aplikacji Java, ale nadal Error 206. Z rzeczy, które czytałem, zdałem sobie sprawę, że moja Ścieżka Budowy jest zbyt długa, ponieważ jest dużo JARS więc teraz Szukam sposobu na skrócenie tej Ścieżki i spakowanie słoików w jeden. Próbowałem wyeksportować folder lib do pliku Jar, ale to nie zadziałało.

EDIT 2

Ostatnią rzeczą, że próbowałem tuż przed momentem jest stworzenie „pathing Jar”, który zawiera tylko MANIFEST.MF pliku wewnątrz niego. Wkładam ten słoik do mojego projektu Ścieżka budowania zamiast wszystkich innych słoików, ale wciąż nie ma wyniku ... teraz projekt zawiera błędy dla ścieżki wbudowanej ...

+0

Brak wystarczającej informacji w odpowiedzi na twoje pytanie. Proszę podać więcej szczegółów o klasie testowej, o tym, jak ją uruchamiasz, dlaczego Twój JAR jest odpowiedni, ... –

+0

Problem rozwiązany! https://bugs.eclipse.org/bugs/show_bug.cgi?id=327193 – cyrat

+0

To dobra wiadomość. Proszę zamieścić odpowiedź na własne pytanie. Możesz wtedy zaakceptować to po 48 godzinach. –

Odpowiedz

4

Należy wykonać następujące kroki:

  1. skopiować eclipse/plugins/org.eclipse.jdt.launching_3.4. *. jar do bezpiecznego miejsca poza folderu plugins, tak aby zawsze mieć sposób, aby przywrócić
  2. blisko Eclipse
  3. Zmień nazwę pliku * .jar na * .zip
  4. otwórz plik zip i skopiuj klasę 4 Pliki z przywiązanie do org \ eclipse \ JDT \ \ wewnętrzny wodowania (zastąpić istniejące pliki)
  5. iść do META-INF w pliku zip i usunąć wszystkie pliki z wyjątkiem MANIFEST.MF
  6. ekstrakt MANIFEST.MF do dysk i edytować go w edytorze tekstu
  7. usunąć wszystko począwszy od pierwszego „name:” entry
  8. upewnij się opuścić dwa (2) znaki podziału wiersza na końcu pliku!
  9. zapisz MANIFEST.MF i skopiuj go z powrotem do pliku zip
  10. zmień nazwę * .zip z powrotem na * .jar
  11. Zamień zmodyfikowany plik jar w twoim katalogu Eclipse/plugin!
  12. Ciesz się!

PS. DODATEK z kroku 4 można pobrać stąd:

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

Dzięki Mr.Markus Keller, którzy stworzyli te kroki!

+0

które 4 klasy trzeba skopiować, ponieważ widzę wiele klas, ale nie potrafię tego rozgryźć w czterech klasach? – user1010399

+0

Mam Eclipse JEE Indigo SR2 (x64), mam niektóre projekty GWT otwarte, a po uruchomieniu Eclipse otrzymałem ten sam komunikat o błędzie od DataNucleus Enhancer. Cieszę się, że kroki opisane w tej odpowiedzi działają również w przypadku tej wersji Eclipse, jedyną różnicą jest numer wersji słoika, którego kopia zapasowa ma zostać utworzona (3.6 zamiast 3.4). Klasy używane do zastąpienia (a mianowicie LongCommandLineLauncher.class, StandardVMDebugger $ ConnectRunnable.class, StandardVMDebugger.class i StandardVMRunner.class) są rzeczywiście nowsze niż oryginalne, chociaż załącznik pochodzi z wersji Eclipse 3.5. –

-1

Rozwiązałem to, wykonując następujące kroki. Wykonaj następujące czynności: Wybierz opcję Projekt-> Właściwości-> wybierz Google App Engine -> ORM i uwzględnij tylko te katalogi, które zawierają klasy, które chcesz ulepszyć.

Powiązane problemy