Spring Tool Suite
  1. Spring Tool Suite
  2. STS-2276

The Gradle task launcher does not repect the JAVA_HOME environment variable

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8.0.RELEASE
    • Fix Version/s: 3.0.0.M1
    • Component/s: GRADLE
    • Labels:
      None

      Description

      I know that once STS-2213 is implemented this would be simpler to address. However, the current situation seems to have a foundamental problem.

      Working in Windows 7 64-bit with 64-bit Eclipse. eclipse.ini specifies the parameter -vm "C:/Program Files/Java/jre6/bin/javaw.exe" (this is a JRE), while the JAVA_HOME environment variable is set to "C:\Program Files\Programmazione\Java\jdk1.6.0_22" (this is a JDK).

      When I try to run a Gradle task with the External Tools Configuration, I get the following incoherent output:

      [sts] -----------------------------------------------------
      [sts] Starting Gradle build for the following tasks: 
      [sts]      :prepareAppletsForEclipse
      [sts] JAVA_HOME is set to 'C:\Program Files\Programmazione\Java\jdk1.6.0_22'
      [sts] -----------------------------------------------------
      [...]
      :MyProject:compileJava
      FAILURE: Build failed with an exception.
      
      * What went wrong:
      Execution failed for task ':MyProject:compileJava'.
      Cause: Unable to find a javac compiler;
      com.sun.tools.javac.Main is not on the classpath.
      Perhaps JAVA_HOME does not point to the JDK.
      It is currently set to "C:\Program Files\Java\jre6"
      

      So, while it first says that the JAVA_HOME is set correctly, once it has to start compiling it complains it is not, because it seems like it's using the "-vm" Eclipse command line argument to resolve the Java location instead of the JAVA_HOME environment variable.

      This said, if I try to remove the JAVA_HOME environment variable and start Eclipse with a JDK (specifying -vm "C:\Program Files\Programmazione\Java\jdk1.6.0_22" command line argument, so overriding what's specified in the eclipse.ini), I get the following output:

      [sts] -----------------------------------------------------
      [sts] Starting Gradle build for the following tasks: 
      [sts]      :prepareAppletsForEclipse
      [sts] JAVA_HOME is NOT SET
      [sts] -----------------------------------------------------
      [...]
      :MyProject:compileJava
      
      FAILURE: Build failed with an exception.
      
      * What went wrong:
      Execution failed for task ':MyProject:compileJava'.
      Cause: Unable to find a javac compiler;
      com.sun.tools.javac.Main is not on the classpath.
      Perhaps JAVA_HOME does not point to the JDK.
      It is currently set to "C:\Program Files\Java\jre6"
      

      (plase note that I've checked that the -vm argument was taken up correctly by Eclipse, by looking at Help | About Eclipse Platform | Installation Details | Configuration)

      This makes me wonder where the hell is the daemon taking that value for the JAVA_HOME environment variable... The only thing I can think of is that my system-wide registered JRE (i.e.: the one that is launched if I open a Command Prompt and type "java -version") is located in "C:\Program Files\Java\jre6" and that the Gradle daemon is taking this by looking at the java.home system property returned by that Java instance.

      So I'm stuck, I don't know how to make Gradle compile when launched from within Eclipse...

        Activity

        Hide
        Mauro Molinari added a comment -

        Please note that in the second example the correct command-line argument should be read as -vm "C:\Program Files\Programmazione\Java\jdk1.6.0_22\bin\javaw.exe". It's just an error in the description, because, as I said, I have checked out that Eclipse is correctly using that JDK in the second example.

        Show
        Mauro Molinari added a comment - Please note that in the second example the correct command-line argument should be read as -vm "C:\Program Files\Programmazione\Java\jdk1.6.0_22\bin\javaw.exe". It's just an error in the description, because, as I said, I have checked out that Eclipse is correctly using that JDK in the second example.
        Hide
        Mauro Molinari added a comment - - edited

        I just found STS-1756. It sounds like this is a duplicate of that bug, althuogh it is marked as "cannot reproduce". I hope at least you can find here some more ideas on what's going on...

        Show
        Mauro Molinari added a comment - - edited I just found STS-1756 . It sounds like this is a duplicate of that bug, althuogh it is marked as "cannot reproduce". I hope at least you can find here some more ideas on what's going on...
        Hide
        Kris De Volder (c) added a comment -

        Hi Mauro,

        Your info is actually very useful. It helps in narrowing down where things are going wrong, unfortunately, I think everything is pointing to it being inside the tooling API's realm and there is nothing that I can do inside STS to fix this.

        It seems to me that when the tooling API is spawning the gradle daemon it may not be passing on environment parameters to the daemon process, then the daemon is falling back to some system default setting.

        In any case this something that is happening completely out of my controll. The only thing that has control over the environment params passed to the daemon process is the code that is spawning the daemon. This is the tooling API, and the tooling API provides nothing for me to set env parameters or the JDK home.

        The only thing I can advise you as a dirty workaround is to make your "C:\Program Files\Java\jre6" actually a symbolic link to the JDK. That way Gradle will find what it needs in the place it is looking for it.

        Show
        Kris De Volder (c) added a comment - Hi Mauro, Your info is actually very useful. It helps in narrowing down where things are going wrong, unfortunately, I think everything is pointing to it being inside the tooling API's realm and there is nothing that I can do inside STS to fix this. It seems to me that when the tooling API is spawning the gradle daemon it may not be passing on environment parameters to the daemon process, then the daemon is falling back to some system default setting. In any case this something that is happening completely out of my controll. The only thing that has control over the environment params passed to the daemon process is the code that is spawning the daemon. This is the tooling API, and the tooling API provides nothing for me to set env parameters or the JDK home. The only thing I can advise you as a dirty workaround is to make your "C:\Program Files\Java\jre6" actually a symbolic link to the JDK. That way Gradle will find what it needs in the place it is looking for it.
        Hide
        Davide Cavestro added a comment -

        Hi Kris,
        do you mind commenting on GRADLE-1691 or GRADLE-1771 the fact that even this bug is blocked by that tooling api issue? (I saw you had a similar discussion for STS-1756)

        Cheers
        Davide

        Show
        Davide Cavestro added a comment - Hi Kris, do you mind commenting on GRADLE-1691 or GRADLE-1771 the fact that even this bug is blocked by that tooling api issue? (I saw you had a similar discussion for STS-1756 ) Cheers Davide
        Hide
        Kris De Volder (c) added a comment -
        Show
        Kris De Volder (c) added a comment - Related issue: http://issues.gradle.org/browse/GRADLE-1852
        Hide
        Carlo Luib-Finetti added a comment - - edited

        I have found my way to circumvent this error with another "dirty workaround". And maybe this is the source of the wrong way determining the locacation of javac.
        I have looked up my Windows 7 registry, and found several entries of "jvm.dll". The root of the evil lies in the entry "JavaSoft/Java Runtime Environment/1.7/Runtime Lib". Here Sun/Oracle writes the full path to "jvm.dll" - but for the JRE. which is different from "JavaSoft/Java Development Kit/1.7", where they have no "Runtime Lib" entry.

        So I hacked these entries (1.7, 1.7.0_02) and let them point to the jvm.dll of the JDK - and voilà, everything is find.

        BTW: my JAVA_HOME is pointing to the JDK; so I cannot figure out why STS looks up for the JRE. After all, it should look up for the "javac.exe", not the "jvm.dll".

        And, after all: Eclipse is allows us to use different JDKs; so why can't STS just use Eclipse to figure out which compiler to use and where it is located on the user's machine?

        Show
        Carlo Luib-Finetti added a comment - - edited I have found my way to circumvent this error with another "dirty workaround". And maybe this is the source of the wrong way determining the locacation of javac. I have looked up my Windows 7 registry, and found several entries of "jvm.dll". The root of the evil lies in the entry "JavaSoft/Java Runtime Environment/1.7/Runtime Lib". Here Sun/Oracle writes the full path to "jvm.dll" - but for the JRE. which is different from "JavaSoft/Java Development Kit/1.7", where they have no "Runtime Lib" entry. So I hacked these entries (1.7, 1.7.0_02) and let them point to the jvm.dll of the JDK - and voilà, everything is find. BTW: my JAVA_HOME is pointing to the JDK; so I cannot figure out why STS looks up for the JRE. After all, it should look up for the "javac.exe", not the "jvm.dll". And, after all: Eclipse is allows us to use different JDKs; so why can't STS just use Eclipse to figure out which compiler to use and where it is located on the user's machine?
        Hide
        Kris De Volder (c) added a comment -

        Hi Carlo, thanks for the info. It may help someone out there .

        Response to your comments about JAVA_HOME:

        It actually doesn't matter what JAVA_HOME is set to because the Gradle Tooling API does not use it to determine which JVM installation to use. In other words, if you have trouble getting Gradle to use the right JVM from STS, setting JAVA_HOME will not help.

        Gradle has its own built-in logic to try and find a JVM and there is nothing that I (or you) can do about it at the moment from the IDE side.

        The Gradle guys (Adam, Szcepan etc.) did promise me that they will provide an API method to select the JVM somehow, soon. When they do, then I will make use of that method so that there is some way for you to set this from the IDE (through some preference or project property page).

        Show
        Kris De Volder (c) added a comment - Hi Carlo, thanks for the info. It may help someone out there . Response to your comments about JAVA_HOME: It actually doesn't matter what JAVA_HOME is set to because the Gradle Tooling API does not use it to determine which JVM installation to use. In other words, if you have trouble getting Gradle to use the right JVM from STS, setting JAVA_HOME will not help. Gradle has its own built-in logic to try and find a JVM and there is nothing that I (or you) can do about it at the moment from the IDE side. The Gradle guys (Adam, Szcepan etc.) did promise me that they will provide an API method to select the JVM somehow, soon. When they do, then I will make use of that method so that there is some way for you to set this from the IDE (through some preference or project property page).
        Hide
        Kris De Volder (c) added a comment -

        Some new API was recently added in Gradle. Pointer sent to me by Szczepan:
        http://gradle.org/docs/nightly/javadoc/org/gradle/tooling/LongRunningOperation.html

        Show
        Kris De Volder (c) added a comment - Some new API was recently added in Gradle. Pointer sent to me by Szczepan: http://gradle.org/docs/nightly/javadoc/org/gradle/tooling/LongRunningOperation.html
        Hide
        Kris De Volder (c) added a comment -

        I've committed a fix.
        There's now an option on the Gradle preferences page to select a JVM install that is configured in your current workspace to set as JAVA_HOME.

        Show
        Kris De Volder (c) added a comment - I've committed a fix. There's now an option on the Gradle preferences page to select a JVM install that is configured in your current workspace to set as JAVA_HOME.
        Hide
        Kris De Volder (c) added a comment - - edited

        I've heard from Szcepan that the new API is not actually working yet. I've disabled this feature in the Gradle/STS UI for now.

        I'm reopening this issue. We will not ship this fix in 2.9.0.M2. Will revisit when Gradle M8 is released.

        Show
        Kris De Volder (c) added a comment - - edited I've heard from Szcepan that the new API is not actually working yet. I've disabled this feature in the Gradle/STS UI for now. I'm reopening this issue. We will not ship this fix in 2.9.0.M2. Will revisit when Gradle M8 is released.
        Hide
        Kris De Volder (c) added a comment -

        Gradle M8 is released, but it is too late to put M8 into RC1. Will try to get to it for RC2.

        Show
        Kris De Volder (c) added a comment - Gradle M8 is released, but it is too late to put M8 into RC1. Will try to get to it for RC2.
        Hide
        Kris De Volder (c) added a comment -

        I tried to enable this functionality with M8, but ran into this problem:
        http://issues.gradle.org/browse/GRADLE-2102

        Putting this on hold again until after M9 is released.

        Show
        Kris De Volder (c) added a comment - I tried to enable this functionality with M8, but ran into this problem: http://issues.gradle.org/browse/GRADLE-2102 Putting this on hold again until after M9 is released.
        Hide
        npace added a comment -

        Any news on this? M9 has been out for a bit now, but it doesn't seem to work with the latest STS snapshot.

        The biggest problem here, is that there does not appear to be a workaround:

        "Gradle has its own built-in logic to try and find a JVM and there is nothing that I (or you) can do about it at the moment from the IDE side."

        That's great, but does anyone know how it works so that we can work around it? Some members of my team don't have this problem, while others do. They all have the same things installed and there appears to be no differences.

        Thanks.

        Show
        npace added a comment - Any news on this? M9 has been out for a bit now, but it doesn't seem to work with the latest STS snapshot. The biggest problem here, is that there does not appear to be a workaround: "Gradle has its own built-in logic to try and find a JVM and there is nothing that I (or you) can do about it at the moment from the IDE side." That's great, but does anyone know how it works so that we can work around it? Some members of my team don't have this problem, while others do. They all have the same things installed and there appears to be no differences. Thanks.
        Hide
        Kris De Volder (c) added a comment -

        No news at this moment. However this is one of the issues that I am targetting for the next milestone 3.0.0.M1 so it will be one of the issues I will be working on in the very near future (next couple of days).

        If you need a workaround, the best suggestion I can come up with is to determine what JVM install is actually being used then make sure that at that very location you have a JDK installed.

        Kris

        Show
        Kris De Volder (c) added a comment - No news at this moment. However this is one of the issues that I am targetting for the next milestone 3.0.0.M1 so it will be one of the issues I will be working on in the very near future (next couple of days). If you need a workaround, the best suggestion I can come up with is to determine what JVM install is actually being used then make sure that at that very location you have a JDK installed. Kris
        Hide
        Kris De Volder (c) added a comment -

        Some news. Unfortunately it doesn't look good for incorporating M9 tooling API.
        see https://issuetracker.springsource.com/browse/STS-2503

        Show
        Kris De Volder (c) added a comment - Some news. Unfortunately it doesn't look good for incorporating M9 tooling API. see https://issuetracker.springsource.com/browse/STS-2503
        Hide
        npace added a comment -

        Thanks Kris. Appreciate all your efforts on this.

        Show
        npace added a comment - Thanks Kris. Appreciate all your efforts on this.
        Hide
        Kris De Volder (c) added a comment -

        No problem.

        Quick update. Looks like the blocking Gradle issue has been resolved. So I'll take a look at using a snapshot build for Gradle RC1 shortly. We may get a solution into 3.0.0.M1 after all

        Kris

        Show
        Kris De Volder (c) added a comment - No problem. Quick update. Looks like the blocking Gradle issue has been resolved. So I'll take a look at using a snapshot build for Gradle RC1 shortly. We may get a solution into 3.0.0.M1 after all Kris
        Hide
        Kris De Volder (c) added a comment -

        Closing issue: just committed a fix. There is now a new preference on the Gradle preferences page that lets user configure a specific JVM install to use for Gradle.

        This is preference is passed on to Gradle via new tooling API that was added recently.

        Show
        Kris De Volder (c) added a comment - Closing issue: just committed a fix. There is now a new preference on the Gradle preferences page that lets user configure a specific JVM install to use for Gradle. This is preference is passed on to Gradle via new tooling API that was added recently.
        Hide
        npace added a comment -

        Hi Chris,

        When will the be available in the snapshot builds?

        Thanks. I look forward to finally getting past this issue!

        Show
        npace added a comment - Hi Chris, When will the be available in the snapshot builds? Thanks. I look forward to finally getting past this issue!
        Hide
        Kris De Volder (c) added a comment -

        I think it is up there now.
        This is the url of the update site:
        http://dist.springsource.com/snapshot/TOOLS/nightly/gradle

        If you have a chance to try it out it would be nice if you can confirm it works for you (or complain if it doesn't

        Cheers,

        Kris

        Show
        Kris De Volder (c) added a comment - I think it is up there now. This is the url of the update site: http://dist.springsource.com/snapshot/TOOLS/nightly/gradle If you have a chance to try it out it would be nice if you can confirm it works for you (or complain if it doesn't Cheers, Kris
        Hide
        npace added a comment -

        Hi Kris,

        Seems to be working, but I did have some flaky behavior initially:

        I upgraded my eclipse plugin to the latest snapshot (2.9.0.201204042228-SNAPSHOT) and updated my gradle wrapper to 1.0-rc-1-20120403220941+0200. I then restarted eclipse and manually killed the gradle daemon. Selected jdk1.6.0_27 in the preferences for the Gradle Eclipse integration. And tried to build a multiproject build. The build did get farther than before and did not complain about JAVA_HOME, but it hung in the middle of the build on a compileJava in a subproject (this project builds in 10 seconds, so I know it hung).

        I was in the middle of writing up the comment, and getting all the version numbers above, and decided to try a gradle clean before a build... and voila! It started working. I now can do build without the clean first without problem.

        I don't know if the clean appearing to fix the hang was coincidental, or if there is a bug in gradle 1.0RC1 that causes hangs when content in the build directory came from an older gradle release?

        Anyhow, seems to be working great! Thank you very much!

        Show
        npace added a comment - Hi Kris, Seems to be working, but I did have some flaky behavior initially: I upgraded my eclipse plugin to the latest snapshot (2.9.0.201204042228-SNAPSHOT) and updated my gradle wrapper to 1.0-rc-1-20120403220941+0200. I then restarted eclipse and manually killed the gradle daemon. Selected jdk1.6.0_27 in the preferences for the Gradle Eclipse integration. And tried to build a multiproject build. The build did get farther than before and did not complain about JAVA_HOME, but it hung in the middle of the build on a compileJava in a subproject (this project builds in 10 seconds, so I know it hung). I was in the middle of writing up the comment, and getting all the version numbers above, and decided to try a gradle clean before a build... and voila! It started working. I now can do build without the clean first without problem. I don't know if the clean appearing to fix the hang was coincidental, or if there is a bug in gradle 1.0RC1 that causes hangs when content in the build directory came from an older gradle release? Anyhow, seems to be working great! Thank you very much!
        Hide
        Kris De Volder (c) added a comment -

        OK, great! Thanks for letting me know.

        I don't know why your initial run got stuck. But it does sound like a problem with Gradle rather than STS.
        If you can reproduce it may be worth submitting a bug report... but if things are working now, perhaps it is best / easiest to leave it alone

        Kris

        Show
        Kris De Volder (c) added a comment - OK, great! Thanks for letting me know. I don't know why your initial run got stuck. But it does sound like a problem with Gradle rather than STS. If you can reproduce it may be worth submitting a bug report... but if things are working now, perhaps it is best / easiest to leave it alone Kris
        Hide
        Mauro Molinari added a comment -

        Hi Kris,
        I'm having a problem now... I don't know if this is the right place.
        This is the situation:

        • no JAVA_HOME set at O.S. level
        • starting Eclipse (with STS 3.1) with JRE 7; this JRE is also the system "default" one (i.e.: if I open a command prompt and type "java -version" I get Java 7)
        • launching a Gradle task from Eclipse => error, can't find a compiler
          Ok, this is reasonable. So, I go to Window | Preferences | Gradle and change the Java Home to a configured workspace JRE, precisely a jdk 1.6.0_22. I re-run the task. Now, Gradle does not complain anymore about the missing compiler, however it gives other errors:
        • many errors like:
          warning: java\lang\Object.class(java\lang:Object.class): major version 51 is newer than 50, the highest major version supported by this compiler.
          It is recommended that the compiler be upgraded.
          
        • another error compiling one of our classes that implements the interface javax.sql.CommonDataSource:
          <myclass> is not abstract and does not override abstract method getParentLogger() in javax.sql.CommonDataSource
          

        In fact, javax.sql.CommonDataSource in Java 7 has a method (getParentLogger()) which is not present in Java 6. Our code is not Java 7 ready and this is a known issue.

        However, the symptoms make me think that however the JAVA_HOME was taken (Gradle seems to be using a Java 6 compiler) it seems like Gradle is using an rt.jar from a Java 7 distribution, rather than that of the Java 6 JDK.

        If I go with the command line, set the JAVA_HOME environment variable and then launch Gradle on the same task, I don't get this error.

        The build.gradle of the root project is specifying version 1.2 of Gradle wrapper. When working with the command line, I'm certainly using Gradle 1.2. By the way, is the option "Use Gradle wrapper's default" in Window | Preferences | Gradle under "Gradle Distribution" meant to be "use your project wrapper as specified in build.gradle" or rather "use the default Gradle wrapper that comes with STS"? I never understood this clearly.

        Show
        Mauro Molinari added a comment - Hi Kris, I'm having a problem now... I don't know if this is the right place. This is the situation: no JAVA_HOME set at O.S. level starting Eclipse (with STS 3.1) with JRE 7; this JRE is also the system "default" one (i.e.: if I open a command prompt and type "java -version" I get Java 7) launching a Gradle task from Eclipse => error, can't find a compiler Ok, this is reasonable. So, I go to Window | Preferences | Gradle and change the Java Home to a configured workspace JRE, precisely a jdk 1.6.0_22. I re-run the task. Now, Gradle does not complain anymore about the missing compiler, however it gives other errors: many errors like: warning: java\lang\Object.class(java\lang:Object.class): major version 51 is newer than 50, the highest major version supported by this compiler. It is recommended that the compiler be upgraded. another error compiling one of our classes that implements the interface javax.sql.CommonDataSource : <myclass> is not abstract and does not override abstract method getParentLogger() in javax.sql.CommonDataSource In fact, javax.sql.CommonDataSource in Java 7 has a method ( getParentLogger() ) which is not present in Java 6. Our code is not Java 7 ready and this is a known issue. However, the symptoms make me think that however the JAVA_HOME was taken (Gradle seems to be using a Java 6 compiler) it seems like Gradle is using an rt.jar from a Java 7 distribution, rather than that of the Java 6 JDK. If I go with the command line, set the JAVA_HOME environment variable and then launch Gradle on the same task, I don't get this error. The build.gradle of the root project is specifying version 1.2 of Gradle wrapper. When working with the command line, I'm certainly using Gradle 1.2. By the way, is the option "Use Gradle wrapper's default" in Window | Preferences | Gradle under "Gradle Distribution" meant to be "use your project wrapper as specified in build.gradle" or rather "use the default Gradle wrapper that comes with STS"? I never understood this clearly.
        Hide
        Kris De Volder (c) added a comment -

        Hi Mauro,

        To be honest with you, I don't hink I have great insight into this problem you are having with Java 6 <-> 7. It sounds to me as if the setting for using your Java 6 JDK is being passed properlly by STS to gradle. Otherwise the 'compiler missing' error would not go away.

        But then, as you say, it seems some Java 7 classes are still on the classpath. I don't know why this would happen. If you are sure they are not put there because your build script added them, then maybe it is an unwanted interaction between the JVM used to run the tooling API/wrapper and the JVM used compile your project's classes. That might make sense, because if you run from the commandline and set JAVA_HOME, I think both the wrapper and the JVM used for compiling your project would be Java 6... But...

        If you run STS with Java 7 and then set Gradle prefs to use Java 6, the tooling api classes are called by STS using a Java 7 but they are supposedly talking to a Daemon configured to use Java 6.

        Perhaps you can try to also start your STS / Eclipse with a Java 6 JDK and see what happens.

        If my guess is correct then I think we should consider this a bug in the tooling API or in Gradle. What JVM you use to run the tooling API client should not affect how this client behaves. It should respect the preference to use a Java 6 JVM.

        In any case, I think we will need some input from the Gradle guys to figure this one out. So maybe take it to the Gradle forum.

        Show
        Kris De Volder (c) added a comment - Hi Mauro, To be honest with you, I don't hink I have great insight into this problem you are having with Java 6 <-> 7. It sounds to me as if the setting for using your Java 6 JDK is being passed properlly by STS to gradle. Otherwise the 'compiler missing' error would not go away. But then, as you say, it seems some Java 7 classes are still on the classpath. I don't know why this would happen. If you are sure they are not put there because your build script added them, then maybe it is an unwanted interaction between the JVM used to run the tooling API/wrapper and the JVM used compile your project's classes. That might make sense, because if you run from the commandline and set JAVA_HOME, I think both the wrapper and the JVM used for compiling your project would be Java 6... But... If you run STS with Java 7 and then set Gradle prefs to use Java 6, the tooling api classes are called by STS using a Java 7 but they are supposedly talking to a Daemon configured to use Java 6. Perhaps you can try to also start your STS / Eclipse with a Java 6 JDK and see what happens. If my guess is correct then I think we should consider this a bug in the tooling API or in Gradle. What JVM you use to run the tooling API client should not affect how this client behaves. It should respect the preference to use a Java 6 JVM. In any case, I think we will need some input from the Gradle guys to figure this one out. So maybe take it to the Gradle forum.
        Hide
        Mauro Molinari added a comment -

        If I run Eclipse with Java 6, then the task succeeds even if run from STS. On the other hand, I saw that if I run gradlew from the command line, the batch file uses JAVA_HOME even to locate the jre used to run Gradle itself. However, this makes the JAVA_HOME setting in STS partially useless. I've written in the Gradle forum as you suggest: http://forums.gradle.org/gradle/topics/relationship_between_the_java_runtime_used_to_run_the_tooling_api_and_the_java_home

        Show
        Mauro Molinari added a comment - If I run Eclipse with Java 6, then the task succeeds even if run from STS. On the other hand, I saw that if I run gradlew from the command line, the batch file uses JAVA_HOME even to locate the jre used to run Gradle itself. However, this makes the JAVA_HOME setting in STS partially useless. I've written in the Gradle forum as you suggest: http://forums.gradle.org/gradle/topics/relationship_between_the_java_runtime_used_to_run_the_tooling_api_and_the_java_home
        Hide
        Kris De Volder (c) added a comment -

        > However, this makes the JAVA_HOME setting in STS partially useless.

        I agree. The JVM used to run the tooling API client (i.e. STS) should not alter the classpath gradle uses to compile your project. Especially if we explicitly tell gradle to use a specific JAVA_HOME.

        So this kind of interaction is probably unintentional and unwanted. Let's wait what they say.

        Show
        Kris De Volder (c) added a comment - > However, this makes the JAVA_HOME setting in STS partially useless. I agree. The JVM used to run the tooling API client (i.e. STS) should not alter the classpath gradle uses to compile your project. Especially if we explicitly tell gradle to use a specific JAVA_HOME. So this kind of interaction is probably unintentional and unwanted. Let's wait what they say.
        Hide
        Mauro Molinari added a comment - - edited

        Hi Kris,
        Peter Niederwieser pointed out that this problem was fixed for http://issues.gradle.org/browse/GRADLE-2460, which is targeted for Gradle 1.3. In fact, I tried to use gradle-1.3-20121016220018+0000-bin.zip in STS and it worked correctly, even when using Java 7 to run Eclipse.
        Thank you for your support!

        By the way, it hasn't to do with this problem, but is the option "Use Gradle wrapper's default" in Window | Preferences | Gradle under "Gradle Distribution" meant to be "use your project wrapper as specified in build.gradle" or rather "use the default Gradle wrapper that comes with STS"? I never understood this clearly.

        Show
        Mauro Molinari added a comment - - edited Hi Kris, Peter Niederwieser pointed out that this problem was fixed for http://issues.gradle.org/browse/GRADLE-2460 , which is targeted for Gradle 1.3. In fact, I tried to use gradle-1.3-20121016220018+0000-bin.zip in STS and it worked correctly, even when using Java 7 to run Eclipse. Thank you for your support! By the way, it hasn't to do with this problem, but is the option "Use Gradle wrapper's default" in Window | Preferences | Gradle under "Gradle Distribution" meant to be "use your project wrapper as specified in build.gradle" or rather "use the default Gradle wrapper that comes with STS"? I never understood this clearly.
        Hide
        Kris De Volder (c) added a comment - - edited

        > "Use Gradle wrapper's default" in Window | Preferences | Gradle under "Gradle Distribution"

        Sorry I thought I ansered that, but maybe I only thought about answering without actually doing it.

        It means that Gradle's decision on what version / distribution to use is not interferred with by STS. I.e. we don't tell Gradle what version or distribution it should use and leave it entirely up to the tooling API. Supposedly, this means it will consult the gradle wrapper properties if it can find them in the expected location. If it can't find them it uses the version programmed into the tooling API (should be the same as the tooling API version).

        Alternatively you select a specific distribution and in that case STS will tell the tooling API to use that specific one. This setting will override any wrapper properties etc.

        If you have a suggestion on what would be a better phrase to put in the prefs page, that's easy enough to change. Any ideas?

        Show
        Kris De Volder (c) added a comment - - edited > "Use Gradle wrapper's default" in Window | Preferences | Gradle under "Gradle Distribution" Sorry I thought I ansered that, but maybe I only thought about answering without actually doing it. It means that Gradle's decision on what version / distribution to use is not interferred with by STS. I.e. we don't tell Gradle what version or distribution it should use and leave it entirely up to the tooling API. Supposedly, this means it will consult the gradle wrapper properties if it can find them in the expected location. If it can't find them it uses the version programmed into the tooling API (should be the same as the tooling API version). Alternatively you select a specific distribution and in that case STS will tell the tooling API to use that specific one. This setting will override any wrapper properties etc. If you have a suggestion on what would be a better phrase to put in the prefs page, that's easy enough to change. Any ideas?
        Hide
        Mauro Molinari added a comment -

        I moved the discussion at: http://forum.springsource.org/showthread.php?131138-quot-Use-Gradle-wrapper-s-default-quot-meaning
        Since it's off topic here. Thanks in advance.

        Show
        Mauro Molinari added a comment - I moved the discussion at: http://forum.springsource.org/showthread.php?131138-quot-Use-Gradle-wrapper-s-default-quot-meaning Since it's off topic here. Thanks in advance.
        Hide
        Carlo Luib-Finetti added a comment -

        Yesterday I prepared a presentation on Gradle and STS Gradle plugin and used some small demo project.

        First, on my computer I stumbled over the error from above "Unable to find a javac compiler;". Then, on the machine of my collegue, to which I copied my Eclipse installation and the demo projects, another strange error happened. On trying to import the Gradle projects, a error dialog box appeared saying something like that: "cannot create JVM - not enough heap space"!

        Then, on my computer I tried to fight the problem by giving the Gradle project a "gradle.properties" file with these contents:

        • org.gradle.daemon=false
        • org.gradle.java.home=D:/java/jdk1.7

        After reloading the project in Eclipse everything worked like it should. So, on the machine of my collegue, I did the same thing, copying the "gradle.properties" to the project directory. After restart of Eclipse, we could import the Gradle project without any error.

        Maybe this helps you with your probs.

        Show
        Carlo Luib-Finetti added a comment - Yesterday I prepared a presentation on Gradle and STS Gradle plugin and used some small demo project. First, on my computer I stumbled over the error from above "Unable to find a javac compiler;". Then, on the machine of my collegue, to which I copied my Eclipse installation and the demo projects, another strange error happened. On trying to import the Gradle projects, a error dialog box appeared saying something like that: "cannot create JVM - not enough heap space"! Then, on my computer I tried to fight the problem by giving the Gradle project a "gradle.properties" file with these contents: org.gradle.daemon=false org.gradle.java.home=D:/java/jdk1.7 After reloading the project in Eclipse everything worked like it should. So, on the machine of my collegue, I did the same thing, copying the "gradle.properties" to the project directory. After restart of Eclipse, we could import the Gradle project without any error. Maybe this helps you with your probs.
        Hide
        Kris De Volder (c) added a comment -

        Carlo that is interesting. I am a bit puzzled however. As far as I know the tooling api will always use the gradle daemon to connect to a target Gradle distribution. Does adding this property in fact stop the daemon and run gradle in the same JVM process as your STS Eclipse? (To answer this question, you can try running 'jps' on the commandline to check if a 'GradleDaemon' process is present).

        If it does stop the daemone then I think setting properties like "org.gradle.java.home=D:/java/jdk1.7" is really useless since it will then automatically be using the same JVM as the host eclipse process?

        Assuming that both properties are actually meaningful and respected by the tooling api... I think it is really impossible that they both be respected at the same time.

        Anyhow... I am still glad it solved your problem however

        And it is certainly also possible I'm completely wrong about how these properties work.

        Show
        Kris De Volder (c) added a comment - Carlo that is interesting. I am a bit puzzled however. As far as I know the tooling api will always use the gradle daemon to connect to a target Gradle distribution. Does adding this property in fact stop the daemon and run gradle in the same JVM process as your STS Eclipse? (To answer this question, you can try running 'jps' on the commandline to check if a 'GradleDaemon' process is present). If it does stop the daemone then I think setting properties like "org.gradle.java.home=D:/java/jdk1.7" is really useless since it will then automatically be using the same JVM as the host eclipse process? Assuming that both properties are actually meaningful and respected by the tooling api... I think it is really impossible that they both be respected at the same time. Anyhow... I am still glad it solved your problem however And it is certainly also possible I'm completely wrong about how these properties work.
        Hide
        Carlo Luib-Finetti added a comment -

        Interesting: you're right Kris. Just started Eclipse on my demo project, ran the "build" task, then called "jps" which shows "2756 GradleDaemon".

        Ok, to verify, I shut down Eclipse, killed the daemon process, set the property "true", restartet Eclipse, built the project, and saw the daemon process. Repeated, this time with property set to "false". Same results: the daemon is started.

        But notice, what I've done just now was on my computer at home; what I reported before was on my computer at work (same OS, same JDK, same Gradle, same Eclipse/STS, although).

        somehow, very confusing -

        Show
        Carlo Luib-Finetti added a comment - Interesting: you're right Kris. Just started Eclipse on my demo project, ran the "build" task, then called "jps" which shows "2756 GradleDaemon". Ok, to verify, I shut down Eclipse, killed the daemon process, set the property "true", restartet Eclipse, built the project, and saw the daemon process. Repeated, this time with property set to "false". Same results: the daemon is started. But notice, what I've done just now was on my computer at home; what I reported before was on my computer at work (same OS, same JDK, same Gradle, same Eclipse/STS, although). somehow, very confusing -
        Hide
        Kris De Volder (c) added a comment -

        Ok, well, it's less confusing if you know that tooling API is simply hardwired to use the daemon. I think that's simply how it is able to connect to different target distributions than the host tooling API version. To do that it needs to run the target gradle in a separate JVM.

        It could be that the "org.gradle.java.home=D:/java/jdk1.7" property is what makes things work for you.

        If so, I think it should also work if you set the Java home via the Gradle preferences page in STS.

        Show
        Kris De Volder (c) added a comment - Ok, well, it's less confusing if you know that tooling API is simply hardwired to use the daemon. I think that's simply how it is able to connect to different target distributions than the host tooling API version. To do that it needs to run the target gradle in a separate JVM. It could be that the "org.gradle.java.home=D:/java/jdk1.7" property is what makes things work for you. If so, I think it should also work if you set the Java home via the Gradle preferences page in STS.

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Mauro Molinari
          • Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: