Gradle игнорирует демон игнорировать пометка

Question

Я бег Gradle 3.2.1 на MacOS X 10.12.1 установлен с brew install gradle, не задавая никакого ENV переменных и т.д. сам, пытается использовать Java-EA:

gradle build -Dorg.gradle.java.home=~/jdk-9.jdk/Contents/Home 

Но сборка не удалась

FAILURE: Сбой сборки с исключением.

• Что пошло не так: не удалось запустить процесс демона. Эта проблема может быть вызвана неправильной настройкой демона. Например, используется непризнанная опция jvm.

Из того, что я знаю, что это не удается, потому что демон пытается использовать опцию MaxPermSize JVM (которая не поддерживается в Java 8+, но в Java 8, это только предупреждение).

Так что я попытался отключить демон:

mkdir -p ~/.gradle && echo "org.gradle.daemon=false" >> ~/.gradle/gradle.properties 

gradle build Но все еще пытается запустить демон ... Я удалил ~/.gradle и .gradle в директории проекта. Любые другие идеи?

$ gradle build -Dorg.gradle.daemon=false -Dorg.gradle.java.home=/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home 
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/3.2.1/userguide/gradle_daemon.html. 

FAILURE: Build failed with an exception. 

* What went wrong: 
Unable to start the daemon process. 
This problem might be caused by incorrect configuration of the daemon. 
For example, an unrecognized jvm option is used. 
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/3.2.1/userguide/gradle_daemon.html 
Please read the following process output to find out more: 
----------------------- 

FAILURE: Build failed with an exception. 

* What went wrong: 
java.lang.ExceptionInInitializerError (no error message) 

* Try: 
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. 


* Try: 
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. 
> Starting Daemon% 

Answer 1

Ok так я понял это, так как я бегу мой билд так:

gradle build -Dorg.gradle.java.home=~/jdk-9.jdk/Contents/Home 

Gradle имеет породить новый поток, чтобы использовать другую версию Java, чем один, на который указывает JAVA_HOME. Это делается путем создания потока демона (даже несмотря на вариант false) с этой версией Java и не работает. То же самое произойдет, если я, по-видимому, передам аргументы JVM в сборку.

Решение заключается в том, чтобы вместо этого установить JAVA_HOME в терминал export JAVA_HOME=~/jdk-9.jdk/Contents/Home и просто запустить gradle build.

Все еще не работает, потому что новейшая версия Java9 сломала отражение Грейдла, но это совсем другая история.

Answer 2

Я размещаю это здесь, так как это слишком большой комментарий (но это точно не ответ).

Если вы запустите свой скрипт с --debug, вы увидите основную ошибку. Я запускаю это прямо через java-9 без установки JAVA_HOME кстати.

У меня был тот же вопрос несколько JDK-9 строит назад и решать ее:

set _JAVA_OPTIONS "-Dsun.reflect.debugModuleAccessChecks=true 
      --add-opens=java.base/java.lang=ALL-UNNAMED 
      --add-opens=java.base/java.util=ALL-UNNAMED 
      --add-opens=java.base/java.lang.invoke=ALL-UNNAMED 
      --add-opens=java.base/java.io=ALL-UNNAMED 
      --add-opens=java.base/java.util.concurrent=ALL-UNNAMED 
      --add-opens=java.base/java.text=ALL-UNNAMED" 

набор вместо экспорта, потому что я использую рыбу, но должен работать на баш то же самое путь.

Интересно это все еще терпит неудачу с билда 153 с этим:

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.util.Map java.util.Collections$UnmodifiableMap.m accessible: module java.base does not "opens java.util" to unnamed module @67080771 

Но что указано в _JAVA_OPTIONS.Это может быть регрессия на сборке 153.