This is also important for STS/Eclipse integration. I have multiple reports of people having issues running Gralde tasks that require the Java compiler. Presumably the problems are due to gradle finding a JRE on their system and using that instead of the JDK.
There currently is no mechanism at all for the IDE to specify which JAVA_HOME gradle ought to use. So no way for me to really fix the problems those users are experiencing.
Kris De Volder
added a comment - This is also important for STS/Eclipse integration. I have multiple reports of people having issues running Gralde tasks that require the Java compiler. Presumably the problems are due to gradle finding a JRE on their system and using that instead of the JDK.
There currently is no mechanism at all for the IDE to specify which JAVA_HOME gradle ought to use. So no way for me to really fix the problems those users are experiencing.
Blocked issues in STS:
https://issuetracker.springsource.com/browse/STS-2276https://issuetracker.springsource.com/browse/STS-1756 (really an older duplicate of 2276)
I don't see that the current task is a duplicate of GRADLE-1240. The current one asks an ability to define jdk to use by gradle (e.g. there are various java5, java6 and java7 versions available at the client's machine). The later talks about configuring jvm settings for the selected jdk.
Denis Zhdanov
added a comment - Hi,
I don't see that the current task is a duplicate of GRADLE-1240. The current one asks an ability to define jdk to use by gradle (e.g. there are various java5, java6 and java7 versions available at the client's machine). The later talks about configuring jvm settings for the selected jdk.
I agree with Denis, calling it a duplicate may be stretching it.
However on the bright side. I do think this issue is now resolved. I even implemented something in STS already that allows the user to pick their JVM to use for Gradle. And I'm now able to pass this info to the tooling API with no problem.
The method in the API is this one:
org.gradle.tooling.LongRunningOperation.setJavaHome(File)
Kris De Volder
added a comment - - edited I agree with Denis, calling it a duplicate may be stretching it.
However on the bright side. I do think this issue is now resolved. I even implemented something in STS already that allows the user to pick their JVM to use for Gradle. And I'm now able to pass this info to the tooling API with no problem.
The method in the API is this one:
org.gradle.tooling.LongRunningOperation.setJavaHome(File)
Szczepan Faber
added a comment - Agreed, duplicate is a stretch. We always considered the args and java location as a same thing internally
Denis, did you notice the org.gradle.tooling.LongRunningOperation.setJavaHome(File) method? Does it solve the problem?
This is also important for STS/Eclipse integration. I have multiple reports of people having issues running Gralde tasks that require the Java compiler. Presumably the problems are due to gradle finding a JRE on their system and using that instead of the JDK.
There currently is no mechanism at all for the IDE to specify which JAVA_HOME gradle ought to use. So no way for me to really fix the problems those users are experiencing.
Blocked issues in STS:
https://issuetracker.springsource.com/browse/STS-2276
https://issuetracker.springsource.com/browse/STS-1756 (really an older duplicate of 2276)