Pomóż mi rozwiązać ten problem. Nie do końca rozumiem, co oznacza błąd w dzienniku.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 21.749s
[INFO] Finished at: Thu Apr 24 10:10:20 IST 2014
[INFO] Final Memory: 15M/37M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on project samples.simpleforwarding: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
[ERROR] Command wascmd.exe /X /C ""C:\Program Files\Java\jdk1.7.0_55\jre\bin\java" -Xmx1024m -XX:MaxPermSize=256m -jar E:\OpenDayLight\controller\opendaylight\samples\simpleforwarding\target\surefire\surefirebooter53410321571238933.jar E:\OpenDayLight\controller\opendaylight\samples\simpleforwarding\target\surefire\surefire86076271125218001tmp E:\OpenDayLight\controller\opendaylight\samples\simpleforwarding\target\surefire\surefire_01846991116135903536tmp"
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
Odpowiedzi:
Miałem ten sam problem i rozwiązałem go dodając:
Cały element wtyczki to:
źródło
.m2
Jest uszkodzona. Usuwanie ~ / .m2 / repozytorium,rm -rf ~/.m2/repository
a następniemvn install
rozwiązanie dla mnie.W moim przypadku problem związany był ze zbyt długim wyjściem dziennika do konsoli IntelliJ IDEA (system operacyjny Windows 10).
Komenda:
To polecenie rozwiązało problem:
źródło
Mam bardzo podobny problem ( kompilacja Maven i wtyczka maven-failafe-Rozwidlona maszyna wirtualna zakończyła się bez właściwego pożegnania ) i znalazłem trzy rozwiązania, które działają dla mnie:
Opis problemu
Problem dotyczy wtyczki maven Wtyczka maven- surefire tylko w wersji 2.20.1 i 2.21.0. Sprawdziłem i używasz wersji 2.20.1.
Rozwiązanie 1
Zaktualizuj wersję wtyczki do 2.22.0 . Dodaj pom.xml :
Rozwiązanie 2
Zmień wersję wtyczki na 2.20 . Dodaj pom.xml :
Rozwiązanie 3
Skorzystaj z testu konfiguracji wtyczki FailureIgnore . Dodaj pom.xml :
źródło
maven:3.6.0-jdk-10
Docker obraz i uaktualnienie do wersji3.0.0-M3
zmaven-surefire-plugin
rozwiązane dla mnie również.Na dzień dzisiejszy (30.10.2018) zauważyliśmy, że nasze kompilacje psują się w Jenkins z tym błędem.
Błąd jest nieco mylący i wymagał spojrzenia na wynik zrzutu,
target/surefire-reports/
aby zobaczyć następujący komunikat o błędzie:Doprowadziło mnie to do następującego postu SO, w którym wspomniano o możliwym błędzie w OpenJDK 181: Maven pewnik nie mógł znaleźć klasy ForkedBooter
Każda z poprawek w tym poście rozwiązuje mój problem. Aby być konkretnym, użyłem jednego z tych:
maven:3.5.4-jdk-8
namaven:3.5.4-jdk-8-alpine
źródło
The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
surefire-reports
.Ta część FAQ Surefire może pomóc:
źródło
Właśnie miałem do czynienia z tym samym problemem, java 8 na Ubuntu
następnie natknąłem się na https://stackoverflow.com/a/53016532/1676516
Wydaje się, że to ostatni błąd we wtyczce surefire w wersji 2.22.1 z java 8 https://issues.apache.org/jira/browse/SUREFIRE-1588
postępował zgodnie z sugerowanym obejściem przez lokalne ustawienia mvn
~/.m2/settings.xml
źródło
Miałem dzisiaj ten sam problem i dla mnie prawdziwy problem został zgłoszony dalej w dzienniku z komunikatem
Pełna konfiguracja wtyczki:Cannot use a threadCount parameter less than 1; 1 > 0
. Podczas dodawania<threadCount>1</threadCount>
w konfiguracji wtyczki surefire drugi błąd zniknął.... i tak, używam zarówno junit, jak i testng w tym środowisku testowym ze względu na kompatybilność wsteczną.
źródło
Miał podobny problem podczas uruchamiania komendy mvn z wtyczką Jacoco na JDK 1.8.0_ 65
Wystąpił błąd w JDK https://bugs.openjdk.java.net/browse/JDK-8081379
Rozwiązaniem było uruchomienie mvn clean install z param -XX: -UseLoopPredicate
Lub po prostu zaktualizuj JDK (myślę, że działa nowa wersja pomocnicza)
źródło
Wyłącz useSystemClassLoader wtyczki maven-surefile-plug powinien pomóc
źródło
Jeśli ktoś dołącza niestandardowy argument argLine, należy ponownie rozważyć, ponieważ jest to prawdopodobnie przyczyną problemów z alokacją pamięci.
Na przykład (kiedyś miałem):
Teraz używam ściśle określonych wartości:
Z jakiegokolwiek powodu aplikacje integrujące się z Surefire, takie jak Jacoco, nie żądają wystarczającej ilości pamięci, aby współistnieć z testami, które mają miejsce podczas kompilacji.
źródło
Wpadłem również na ten problem w kontenerze Jenkins Docker (próbowałem jenkins: lts, jenkins, jenkins: slim i jenkins: slim-lts. Nie chciałem przeglądać wszystkich repozytoriów i aktualizować pom dla każdego projektu, więc właśnie dodałem disableClassPathURLCheck do wywołania linii poleceń maven:
źródło
Używając maven surefire 2.21.0 Rozwiązałem problem zmiany
reuseForks
wartości opcji z prawdy na fałsz :Cała moja sekcja konfiguracji w trakcie budowy wyglądała następująco:
źródło
Musisz sprawdzić, czy twój komputer jest 64-bitowy czy 32-bitowy. Jeśli twój komputer jest 32-bitowy, argument pamięci nie powinien przekraczać 4096, nawet poniżej 4 GB. ale jeśli twój komputer jest 64-bitowy, zainstaluj Java 64-bitowy i podaj JAVA_HOME w mvn.bat, które wskazują na 64-bitową instalację Java.
źródło
Spotkałem przypadek, w którym żadna z podanych odpowiedzi nie rozwiązała problemu. Było to ze starszą aplikacją, która akurat używa log4j i SLF4J / logback.
Poprzednia sytuacja:
clean test
kompilacje działały poprawnie po uruchomieniu z poziomu Eclipse, ale po uruchomieniu w linii poleceń wystąpił ten błąd. Kompilacje CI na CircleCI również działały dobrze.To, co zrobiłem: z czystego zgadywania, to skonfigurowanie właściwego
logback-test.xml
i obniżenie szczegółowości rejestrowania. I oto, nie doświadczyłem już tego błędu i mogę teraz zbudować projekt (a także moduł, w którym ten błąd występował) z wiersza poleceń.Chodzi mi o to, że sposób, w jaki struktury rejestrowania są używane lub konfigurowane, może być innym wyjaśnieniem .
Czy to naprawdę był konflikt między log4j a logback? A może po prostu duża ilość rejestrowania wynikająca z testów w jakiś sposób przepełniła bufor linii poleceń? Nie wiem Pozostaje mi to tajemnicą.
źródło
Podobny problem spotkałem po aktualizacji do java 12, dla mnie rozwiązaniem była aktualizacja wersji jacoco
<jacoco.version>0.8.3</jacoco.version>
źródło
wersja 2.22.2 ma prawdziwe problemy z rozwidlonymi maszynami JVM. Użyj wersji 2.20 - działa jak urok!
źródło
v2.22.2
ma problem zmaven:3.6-jdk-8-alpine
. Tak denerwujące!Niedawno utknąłem w tym błędzie podczas tworzenia aplikacji kontenerowych w słoikach za pomocą Bamboo:
Po wielu godzinach badań naprawiłem to. Pomyślałem, że warto udostępnić tutaj moje rozwiązanie.
Tak więc błąd występuje za każdym razem, gdy
mvn clean package
polecenie uruchamiania z bambusa dla aplikacji Java w kontenerach dokowanych. Nie jestem ekspertem od Maven, ale problem tkwił w wtyczkach Surefire i Junit4 dołączonych do Spring-boot jako zależność od maven.Aby to naprawić, musisz wymienić Junit4 na Junit5 i zastąpić wtyczkę Surefire
pom.xml
.1.Wewnętrzne wyłączenie wstawki zależności rozruchu sprężynowego:
2. Dodaj nowe zależności Junit5:
3. Wstaw nową wtyczkę do sekcji wtyczek
To powinno wystarczyć do naprawy bambusowych kompilacji. Nie zapomnij również przekształcić wszystkich testów Junit4 na obsługę Junit5.
źródło
Ustawienie tego w pom.xml działało dla mnie. Ale należy sprawdzić dokumentację pod kątem innych obejść https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html
źródło
W rozwidlonej maszynie JVM użytej w teście zabrakło pamięci. Rozwiązaniem byłoby albo wyłączenie rozwidlania JVM i uruchomienie testów na głównej JVM, upewniając się, że masz wystarczającą pamięć, lub przekazanie argumentów w celu zwiększenia pamięci rozwidlonej JVM
Sprawdź rozwiązanie w tej odpowiedzi
źródło
Natrafiłem na ten problem podczas kompilacji Jenkinsa na maszynie Ubuntu.
/var/log/syslog
zgłoszoneOut of memory: Kill process 19557 (java) score 207 or sacrifice child
.Dlatego dałem maszynie Ubuntu więcej przestrzeni wymiany . Od tego czasu problem zniknął.
źródło
Moim rozwiązaniem tego problemu było zamknięcie przeklętej przeglądarki Chrome, która dusiła pamięć mojego komputera 🙄
źródło
Możesz ustawić opcje java
SET JAVA_OPTS='-Xmx1024m' XX:+UseLoopPredicate
mvn clean install
źródło
W systemie Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1) mam tę główną przyczynę:
i rozwiązane przez zwiększenie rozmiaru pliku stronicowania, np . w ten sposób .
źródło
próbowałem wszystkiego powyżej, nie działało. poniższe rozwiązanie działa dla mnie:
źródło
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T21:41:47+03:00) Java version: 1.8.0_201, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_201\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Miałem ten sam problem i rozwiązałem go, używając Java 8 z Oracle zamiast Java 10 z Openjdk
źródło
Próbowałem wszystkich dostarczonych rozwiązań (rozwidlanie, ładowanie systemu, więcej pamięci itp.), Nic nie działało.
Środowisko : kompilacja nie powiodła się w środowisku gitlab ci, uruchamiając kompilację w kontenerze dokera.
Rozwiązanie : Użyliśmy surefireplugin w wersji 2.20.1 i aktualizacja do wersji 2.21.0 lub nowszej (użyliśmy wersji 2.22.1) rozwiązała ten problem.
Przyczyna : SUREFIRE-1422 - surefire używa polecenia
ps
, które nie było dostępne w środowisku dokera i doprowadziło do „awarii”. Ten problem został rozwiązany w wersji 2.21.0 lub nowszej.Dzięki tej odpowiedzi z innego pytania: https://stackoverflow.com/a/50568662/2970422
źródło
Natknąłem się również na ten problem na MacOS podczas zdalnego debugowania kodu testowego Selenium na porcie 5005. Problem okazał się być spowodowany pozostawioną uruchomioną maszyną JVM surefire-forked-forked. Dane wyjściowe dziennika do terminala Eclipse IDE nie wykazały podstawowego problemu, którym był już adres . Komunikat dziennika był wyświetlany tylko wtedy, gdy uruchomiłem to samo polecenie w terminalu MacOS, które Eclipse faktycznie próbował uruchomić:
/bin/sh -c cd /path/to/your/project/directory && /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/bin/java -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -jar /path/to/target/surefire/surefirebooter230340673926465933.jar /path/to/target/surefire 2019-06-28T10-50-02_140-jvmRun1 surefire6455775580414993159tmp surefire_02461993428448591420tmp
Zabicie nieuczciwej instancji JVM (poszukaj nazwy procesu java w Activity Monitor) rozwiązało problem. Przy okazji używam wtyczki surefire w wersji 2.21.0 bez problemów z otwartym jdk 8 (v1.8.0_212). Zauważ, że wszystkie ścieżki będą specyficzne dla twojego środowiska kompilacji i ewentualnie portu (adres = 5005).
źródło
Napotkałem ten sam problem podczas uruchamiania testów jednostkowych za pomocą testu maven. Próbowałem zmienić wersje surefire, ale to nie działa. W końcu udało się rozwiązać w następujący sposób: WCZEŚNIEJ: (gdy problem się pojawiał): javac pochodzi z jdk 1.8 java wskazuje na bin java z jdk 1.11 CURRENT: (kiedy problem został rozwiązany): zarówno javac, jak i java wskazują pojemniki z jdk 1.8
Pozdrawiam Teja.
źródło
Wystąpił ten błąd po tym, jak statyczna zmienna składowa w mojej klasie testowej wywołała metodę utworzenia obiektu (która była używana w testowych przypadkach w całej klasie), a metoda spowodowała wyjątek.
Niektóre poprawki obejmują odtworzenie obiektu wewnątrz każdego przypadku testowego i odpowiednie wychwycenie wyjątków. Lub poprzez zainicjowanie obiektu w metodzie @BeforeTest i upewnienie się, że jest on poprawnie zbudowany.
źródło
W moim przypadku problem dotyczył zbyt długiej ścieżki obszaru roboczego. Więc zrobiłem refaktoryzację ścieżki i to rozwiązało problem.
źródło