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

Problems passing JAVA_HOME to Gradle tasks

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 2.7.0.M1
    • Fix Version/s: 2.7.0.RC1
    • Component/s: GRADLE
    • Environment:

      Windows

      Description

      User reported a problem because of Java being a JRE on windows:

      http://gradle.1045684.n5.nabble.com/ANN-Gradle-Eclipse-Plugin-tt4387658.html#a4393115

      Not clear at this point why his JAVA_HOME environment variable isn't getting to where the task is trying to call the compiler. Could be that its lost before it even gets to the Eclipse process.

        Activity

        Hide
        David Sowerby added a comment -

        I'm not sure that bug is related to passing the JAVA_HOME value. I was about to post the following on the Gradle user group; it may be relevant to this bug report as well.
        -----------------

        I had a new install of 1.0M3 but was baffled by an error report running a build file with the java and eclipse plugins:

        Execution failed for task ':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 "/usr/lib/jvm/java-6-openjdk/jre"

        This was odd because java is definitely installed on this path.

        I thought I had one successful build while checking the installation, but wasn't sure. I even installed 0.9.2 to double check, and that was the same.
        I used the build.gradle file from the samples/java/quickstart, still the same.

        Eventually I narrowed it down to the structure of the target - I had copied another java project and it was structured as /src/main/java/com .... and failed

        If I change the structure to either /src/main/com ... or src/com ... there is no error. This is repeatable.

        It is not a problem now that I know the cause, but this error message is misleading - it suggests something very different, perhaps that something has failed but fallen through to a catch-all exception.

        Show
        David Sowerby added a comment - I'm not sure that bug is related to passing the JAVA_HOME value. I was about to post the following on the Gradle user group; it may be relevant to this bug report as well. ----------------- I had a new install of 1.0M3 but was baffled by an error report running a build file with the java and eclipse plugins: Execution failed for task ':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 "/usr/lib/jvm/java-6-openjdk/jre" This was odd because java is definitely installed on this path. I thought I had one successful build while checking the installation, but wasn't sure. I even installed 0.9.2 to double check, and that was the same. I used the build.gradle file from the samples/java/quickstart, still the same. Eventually I narrowed it down to the structure of the target - I had copied another java project and it was structured as /src/main/java/com .... and failed If I change the structure to either /src/main/com ... or src/com ... there is no error. This is repeatable. It is not a problem now that I know the cause, but this error message is misleading - it suggests something very different, perhaps that something has failed but fallen through to a catch-all exception.
        Hide
        Kris De Volder (c) added a comment -

        Hi David,

        If its the case that the problem isn't because of JDK versus JRE then it would be a problem with Gradle itself and not an STS bug. (The error comes from inside Gradle).

        I would not rule out however that we may have issues with passing info down about the JDK install. It may very well be that if you actually do have a JDK versus JRE issue you will also get this error message.

        It is good to know, however, that you have seen this error being caused by some unrelated problem. So thanks for posting here.

        Kris

        Show
        Kris De Volder (c) added a comment - Hi David, If its the case that the problem isn't because of JDK versus JRE then it would be a problem with Gradle itself and not an STS bug. (The error comes from inside Gradle). I would not rule out however that we may have issues with passing info down about the JDK install. It may very well be that if you actually do have a JDK versus JRE issue you will also get this error message. It is good to know, however, that you have seen this error being caused by some unrelated problem. So thanks for posting here. Kris
        Hide
        Kris De Volder (c) added a comment -

        David,

        Do you have a sample project that causes the problem? If you could attach it here, I could explore what's going on using a Debugger. Issues like this can be quite frustrating to users, so if there's something we
        can do about it, we should.

        Kris

        Show
        Kris De Volder (c) added a comment - David, Do you have a sample project that causes the problem? If you could attach it here, I could explore what's going on using a Debugger. Issues like this can be quite frustrating to users, so if there's something we can do about it, we should. Kris
        Hide
        Kris De Volder (c) added a comment -

        I'm going to resolve this as cannot reproduce. If we see similar problems in the future, we can create a new issue.

        Show
        Kris De Volder (c) added a comment - I'm going to resolve this as cannot reproduce. If we see similar problems in the future, we can create a new issue.
        Hide
        npace added a comment -

        Can we get this reopened. Half of our team is experiencing the same issue on our project. Everything seems the same in our environments, but for some people they get this error, others they don't. It doesn't have anything to do with the project structure. Moving things around appear to resolve the problem, but then upon closer inspection it turns out the java classes are not compiled (having been new to Gradle we didn't know how it found java files to compile). But adjusting the paths in the build.gradle to match will continue to cause the problem once gradle tries to use the compiler.

        Thank you.

        Show
        npace added a comment - Can we get this reopened. Half of our team is experiencing the same issue on our project. Everything seems the same in our environments, but for some people they get this error, others they don't. It doesn't have anything to do with the project structure. Moving things around appear to resolve the problem, but then upon closer inspection it turns out the java classes are not compiled (having been new to Gradle we didn't know how it found java files to compile). But adjusting the paths in the build.gradle to match will continue to cause the problem once gradle tries to use the compiler. Thank you.
        Hide
        Kris De Volder (c) added a comment -

        I've reopened the issue. I should note however that Gradle tooling API doesn't provide any means at the moment to specify the Java install it will/should use.

        So while I'm certainly willing to dig into this a little with you, in trying to diagnose the problem, I doubt that there is something I can fix in STS to make the problem go away.

        There is an issue open against Gradle itself related to passing settings like environment variables, Java install location, Java options, and system properties (none of these are possible at the moment).
        See: http://issues.gradle.org/browse/GRADLE-1691

        That means the mechanism by which Gradle determines which Java home to use is completely opaque to STS and STS has no control over it. So it may be worthwhile trying to ask some questions on Gradle user or Gradle dev mailing list as well. There could be something that actually lets you specify the Java home/compiler as an option of the java-plugin, in your build script.

        Also you could add some comments about your problems to Gradle-1691 and vote for the issue.

        > It doesn't have anything to do with the project structure.

        I wouldn't expect so.

        I could suggest a workaround, though it is a bit hacky. Try to make sure that whatever lives in the location where Gradle is looking for Java, it has a JDK installed rather than a JRE. (E.g. simply do not install a JRE, only install a single Java version in the default location and make sure it is a JDK).

        I've also heard from some users that they simply linked the default JRE location to wherever they had their JDK installed and deleted the JRE. This seemed to work for them.

        Show
        Kris De Volder (c) added a comment - I've reopened the issue. I should note however that Gradle tooling API doesn't provide any means at the moment to specify the Java install it will/should use. So while I'm certainly willing to dig into this a little with you, in trying to diagnose the problem, I doubt that there is something I can fix in STS to make the problem go away. There is an issue open against Gradle itself related to passing settings like environment variables, Java install location, Java options, and system properties (none of these are possible at the moment). See: http://issues.gradle.org/browse/GRADLE-1691 That means the mechanism by which Gradle determines which Java home to use is completely opaque to STS and STS has no control over it. So it may be worthwhile trying to ask some questions on Gradle user or Gradle dev mailing list as well. There could be something that actually lets you specify the Java home/compiler as an option of the java-plugin, in your build script. Also you could add some comments about your problems to Gradle-1691 and vote for the issue. > It doesn't have anything to do with the project structure. I wouldn't expect so. I could suggest a workaround, though it is a bit hacky. Try to make sure that whatever lives in the location where Gradle is looking for Java, it has a JDK installed rather than a JRE. (E.g. simply do not install a JRE, only install a single Java version in the default location and make sure it is a JDK). I've also heard from some users that they simply linked the default JRE location to wherever they had their JDK installed and deleted the JRE. This seemed to work for them.
        Hide
        Kris De Volder (c) added a comment -

        Another possibly relevant open Gradle bug:
        http://issues.gradle.org/browse/GRADLE-1757

        Note that STS uses the tooling API and this always uses the gradle daemon, so the issue most likely affects running tasks from within STS.

        Show
        Kris De Volder (c) added a comment - Another possibly relevant open Gradle bug: http://issues.gradle.org/browse/GRADLE-1757 Note that STS uses the tooling API and this always uses the gradle daemon, so the issue most likely affects running tasks from within STS.
        Hide
        npace added a comment -

        Hi Kris,

        It seems that STS should have some level of control over this by setting the JAVA_HOME before calling the Gradle tooling api. Perhaps the problem is with the daemon, and the environment variables are not getting passed? Perhaps, having the ability to not use the daemon in the STS would reveal if that is true, but there is currently no way to tell STS not to use the daemon (and maybe you can't through the tooling api, I haven't looked into it).

        Just FYI, this happens on 1.0M5 and the latest STS snapshot. But only when launching from the STS eclipse plugin. If we create an external tool profile that runs gradle.bat, everything works fine. We've tried killing the daemon and changing various installed JDK/JRE settings with no effect. We've also tried passing the JAVA_HOME to eclipse, but it seems that eclipse ignores it - I don't have the references but others on the internet have said as much.

        Show
        npace added a comment - Hi Kris, It seems that STS should have some level of control over this by setting the JAVA_HOME before calling the Gradle tooling api. Perhaps the problem is with the daemon, and the environment variables are not getting passed? Perhaps, having the ability to not use the daemon in the STS would reveal if that is true, but there is currently no way to tell STS not to use the daemon (and maybe you can't through the tooling api, I haven't looked into it). Just FYI, this happens on 1.0M5 and the latest STS snapshot. But only when launching from the STS eclipse plugin. If we create an external tool profile that runs gradle.bat, everything works fine. We've tried killing the daemon and changing various installed JDK/JRE settings with no effect. We've also tried passing the JAVA_HOME to eclipse, but it seems that eclipse ignores it - I don't have the references but others on the internet have said as much.
        Hide
        Kris De Volder (c) added a comment -

        > It seems that STS should have some level of control over this by setting the JAVA_HOME
        > before calling the Gradle tooling api.

        At first I thought it is not possible to set JAVA_HOME before calling the tooling API because calling the tooling API is only calling methods in the same process that STS is running. I think setting environment variables only can be done upon launching new processes. With the tooling API, it the API that starts the deamon process. So it the API that is in control of passing anything liken environment variables to that daemon.

        However, prehaps you are right. I could maybe try setting the global env parameter via ProcessBuilder.environment... which may affect the daemon process (or any process started by STS for that matter). I'm a bit scared of doing that, because this global setting may also affect other things, not just the gradle deamon. But it is worth a try. I'll post follow up with my findings later.

        > Perhaps the problem is with the daemon, and the environment variables are not getting passed?

        I am not certain of that, but it seems likely, given bug GRADLE-1757 which is unresolved.

        > If we create an external tool profile that runs gradle.bat, everything works fine.

        Yes, I would expect so. This because then you are using eclipse launching framework which gives full control over all the parameters passed to the external process, including environment parameters etc. So this can be made to work exactly like you would run Gradle from the commandline. Also in that case you are not running via the deamon.

        The tooling API unfortunately affords none of this control and has its own mechanism for running Gradle via the Gradle daemon. In principle it should be the same, but in practice it is not.

        > We've tried killing the daemon and changing various installed JDK/JRE settings with no effect.

        I don't know what mechanism Gradle uses to determine the Java install it will use the launch the daemon and Java compiler tasks in the build script. So I can't help much there. I'd suggest asking on Gradle mailing lists or forum about this.

        However, if I were to guess how it works, I would imagine it consults JAVA_HOME and if this isn't set looks for certain default locations based on your platform. But this is just a guess of course.

        What I was suggesting, which is really a very dirty hack, is to try and determine which Java version it actually finds on your machine. When you know which one that is, then make sure that whatever lives at that location is a JDK. Remove the existing JRE install that lives there altogether and replace it with a JDK in the same location. This should work.

        I don't like this kind of hackery, but don't really have anything better to suggest, unless Gradle adds some stuff to the tooling API to allow explicititly setting the Java Home passed to the daemon process.

        > Perhaps, having the ability to not use the daemon in STS would reveal if that is true, but there is
        > currently no way to tell STS not to use the daemon (and maybe you can't through the tooling api, I
        > haven't looked into it).

        Right, the tooling API doesn't have an option to 'turn off' the daemon.
        See also this bug report (not directly related, but has some info about this):

        http://issues.gradle.org/browse/GRADLE-1594

        Show
        Kris De Volder (c) added a comment - > It seems that STS should have some level of control over this by setting the JAVA_HOME > before calling the Gradle tooling api. At first I thought it is not possible to set JAVA_HOME before calling the tooling API because calling the tooling API is only calling methods in the same process that STS is running. I think setting environment variables only can be done upon launching new processes. With the tooling API, it the API that starts the deamon process. So it the API that is in control of passing anything liken environment variables to that daemon. However, prehaps you are right. I could maybe try setting the global env parameter via ProcessBuilder.environment... which may affect the daemon process (or any process started by STS for that matter). I'm a bit scared of doing that, because this global setting may also affect other things, not just the gradle deamon. But it is worth a try. I'll post follow up with my findings later. > Perhaps the problem is with the daemon, and the environment variables are not getting passed? I am not certain of that, but it seems likely, given bug GRADLE-1757 which is unresolved. > If we create an external tool profile that runs gradle.bat, everything works fine. Yes, I would expect so. This because then you are using eclipse launching framework which gives full control over all the parameters passed to the external process, including environment parameters etc. So this can be made to work exactly like you would run Gradle from the commandline. Also in that case you are not running via the deamon. The tooling API unfortunately affords none of this control and has its own mechanism for running Gradle via the Gradle daemon. In principle it should be the same, but in practice it is not. > We've tried killing the daemon and changing various installed JDK/JRE settings with no effect. I don't know what mechanism Gradle uses to determine the Java install it will use the launch the daemon and Java compiler tasks in the build script. So I can't help much there. I'd suggest asking on Gradle mailing lists or forum about this. However, if I were to guess how it works, I would imagine it consults JAVA_HOME and if this isn't set looks for certain default locations based on your platform. But this is just a guess of course. What I was suggesting, which is really a very dirty hack, is to try and determine which Java version it actually finds on your machine. When you know which one that is, then make sure that whatever lives at that location is a JDK. Remove the existing JRE install that lives there altogether and replace it with a JDK in the same location. This should work. I don't like this kind of hackery, but don't really have anything better to suggest, unless Gradle adds some stuff to the tooling API to allow explicititly setting the Java Home passed to the daemon process. > Perhaps, having the ability to not use the daemon in STS would reveal if that is true, but there is > currently no way to tell STS not to use the daemon (and maybe you can't through the tooling api, I > haven't looked into it). Right, the tooling API doesn't have an option to 'turn off' the daemon. See also this bug report (not directly related, but has some info about this): http://issues.gradle.org/browse/GRADLE-1594
        Hide
        Kris De Volder (c) added a comment -

        OK, I looked a bit closer at the Java API for setting environment parameters like JAVA_HOME. It looks like my initial idea about it was actually right. You only get to set the environment parameters if you are the one actually starting the process. This means only the tooling API can do this.

        The Java API has been carefully and deliberately designed to make it this way:

        • System.getEnv only returns a read-only map
        • There is no System.setEnv
        • ProcessBuilder.environment() method is an instance method so can only be called by someone having access to the processbuilder that actually starts the proces (in this case the tooling API).

        See also here:
        http://stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java

        Some people there suggested some Java reflection hackery to circumvent the API design by directly mutating private fields in the System class... but I don't think I want to go that far to make this work, since it is a questionable solution which has the potential of breaking other processes STS launches in unexpected ways.

        Show
        Kris De Volder (c) added a comment - OK, I looked a bit closer at the Java API for setting environment parameters like JAVA_HOME. It looks like my initial idea about it was actually right. You only get to set the environment parameters if you are the one actually starting the process. This means only the tooling API can do this. The Java API has been carefully and deliberately designed to make it this way: System.getEnv only returns a read-only map There is no System.setEnv ProcessBuilder.environment() method is an instance method so can only be called by someone having access to the processbuilder that actually starts the proces (in this case the tooling API). See also here: http://stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java Some people there suggested some Java reflection hackery to circumvent the API design by directly mutating private fields in the System class... but I don't think I want to go that far to make this work, since it is a questionable solution which has the potential of breaking other processes STS launches in unexpected ways.
        Hide
        npace added a comment -

        Hi Kris,

        > Some people there suggested some Java reflection hackery to circumvent
        > the API design by directly mutating private fields in the System
        > class... but I don't think I want to go that far to make this work,
        > since it is a questionable solution which has the potential of breaking>
        > other processes STS launches in unexpected ways.

        I agree with you there. That's not something a well-behaved plugin should be doing.

        All-in-all, the thing that I find most confusing, is this consistently works on some of our developer's environments. And we don't know why, as everything appears equal. This is what's made me believe initially that it's not necessarily a Gradle bug. If it was, I would have expected the bug to manifest for many more users of the plugin, and all of our developers.

        The only thing I can think of is to see if JAVA_HOME is set before calling the tooling API. I would expect that it is not in the cases were the Gradle plugin does not work, and that it is set in the cases where it does work. If that's true, then perhaps we can rule out Gradle, and focus on why it's set in some environments and not in others.

        I'm not an eclipse plugin developer though, so I'm not sure how to go about this without a lot of research/work. Any suggestions on how to probe the JAVA_HOME env value before the Gradle tooling API gets called? Maybe a debug setting in the STS plugin that will dump some useful values to a log?

        Thanks!

        Show
        npace added a comment - Hi Kris, > Some people there suggested some Java reflection hackery to circumvent > the API design by directly mutating private fields in the System > class... but I don't think I want to go that far to make this work, > since it is a questionable solution which has the potential of breaking> > other processes STS launches in unexpected ways. I agree with you there. That's not something a well-behaved plugin should be doing. All-in-all, the thing that I find most confusing, is this consistently works on some of our developer's environments. And we don't know why, as everything appears equal. This is what's made me believe initially that it's not necessarily a Gradle bug. If it was, I would have expected the bug to manifest for many more users of the plugin, and all of our developers. The only thing I can think of is to see if JAVA_HOME is set before calling the tooling API. I would expect that it is not in the cases were the Gradle plugin does not work, and that it is set in the cases where it does work. If that's true, then perhaps we can rule out Gradle, and focus on why it's set in some environments and not in others. I'm not an eclipse plugin developer though, so I'm not sure how to go about this without a lot of research/work. Any suggestions on how to probe the JAVA_HOME env value before the Gradle tooling API gets called? Maybe a debug setting in the STS plugin that will dump some useful values to a log? Thanks!
        Hide
        Kris De Volder (c) added a comment - - edited

        When this bug was first raised, I added a little bit of code to the gradle STS task launcher to print out JAVA_HOME just before the task is launched. If you look in the console where it shows the output for the task execution, you should see something like this:

        [sts] -----------------------------------------------------
        [sts] Starting Gradle build for the following tasks: 
        [sts]      :build
        [sts] JAVA_HOME is NOT SET
        [sts] -----------------------------------------------------
        Note: the Gradle build daemon is an experimental feature.
        As such, you may experience unexpected build failures. You may need to occasionally stop the daemon.
        ...
        

        The lines at the start with [sts] are printed by STS code before the call to the tooling API. They print the value of JAVA_HOME of the STS process (as returned by System.getEnv()).

        I don't know if it makes a difference or not whether it is set there, (given GRADLE-1757, maybe it makes no difference). But at least you should be able to tell whether it is set and what it is set too for the STS process.

        To see what it is set to in the build script, you can call System.getEnv() from within your build script and print it out yourself. Maybe that way you can track down how the value of JAVA_HOME flows from launching STS to launching Gradle.

        > All-in-all, the thing that I find most confusing, is this consistently
        > works on some of our developer's environments. And we don't know why,
        > as everything appears equal. This is what's made me believe initially
        > that it's not necessarily a Gradle bug. If it was, I would have expected
        > the bug to manifest for many more users of the plugin, and all of our developers.

        I gather the bug (if it is a bug in Gradle) would only manifest in some systems, depending on what JRE/JDK versions are installed and in what locations. Users who only have a JDK installed wouldn't have any issues.
        So it may affect fewer users... assuming most developers might only install a JDK instead of a JRE.

        I don't know what might be different, but something must be...

        Perhaps you could run a system wide search for typical jar files found in a Java install. For example "rt.jar". This is found in a typical sun JVM install under <JAVA_HOME>jre/lib/rt.jar

        Hopefully that will reveal all the places where a JRE or JDK install exists on those machines. Then pay very close attention to difference between their locations, and whether they are JREs or JDKs.

        To check whether an install is a JDK, check if it has a tools.jar under <JAVA_HOME>lib/tools.jar.
        Don't rely just on the name of the java home. It may be called 'jre' but still actually be a JDK installed in that location.

        Show
        Kris De Volder (c) added a comment - - edited When this bug was first raised, I added a little bit of code to the gradle STS task launcher to print out JAVA_HOME just before the task is launched. If you look in the console where it shows the output for the task execution, you should see something like this: [sts] ----------------------------------------------------- [sts] Starting Gradle build for the following tasks: [sts] :build [sts] JAVA_HOME is NOT SET [sts] ----------------------------------------------------- Note: the Gradle build daemon is an experimental feature. As such, you may experience unexpected build failures. You may need to occasionally stop the daemon. ... The lines at the start with [sts] are printed by STS code before the call to the tooling API. They print the value of JAVA_HOME of the STS process (as returned by System.getEnv()). I don't know if it makes a difference or not whether it is set there, (given GRADLE-1757, maybe it makes no difference). But at least you should be able to tell whether it is set and what it is set too for the STS process. To see what it is set to in the build script, you can call System.getEnv() from within your build script and print it out yourself. Maybe that way you can track down how the value of JAVA_HOME flows from launching STS to launching Gradle. > All-in-all, the thing that I find most confusing, is this consistently > works on some of our developer's environments. And we don't know why, > as everything appears equal. This is what's made me believe initially > that it's not necessarily a Gradle bug. If it was, I would have expected > the bug to manifest for many more users of the plugin, and all of our developers. I gather the bug (if it is a bug in Gradle) would only manifest in some systems, depending on what JRE/JDK versions are installed and in what locations. Users who only have a JDK installed wouldn't have any issues. So it may affect fewer users... assuming most developers might only install a JDK instead of a JRE. I don't know what might be different, but something must be... Perhaps you could run a system wide search for typical jar files found in a Java install. For example "rt.jar". This is found in a typical sun JVM install under <JAVA_HOME>jre/lib/rt.jar Hopefully that will reveal all the places where a JRE or JDK install exists on those machines. Then pay very close attention to difference between their locations, and whether they are JREs or JDKs. To check whether an install is a JDK, check if it has a tools.jar under <JAVA_HOME>lib/tools.jar. Don't rely just on the name of the java home. It may be called 'jre' but still actually be a JDK installed in that location.
        Hide
        Kris De Volder (c) added a comment -

        Note: http://issues.gradle.org/browse/GRADLE-1757 has just been resolved.

        Show
        Kris De Volder (c) added a comment - Note: http://issues.gradle.org/browse/GRADLE-1757 has just been resolved.
        Hide
        Kris De Volder (c) added a comment -

        Hi npace,

        Anything new? Did you figure out what is going on on the machines where you had problems?

        Kris

        Show
        Kris De Volder (c) added a comment - Hi npace, Anything new? Did you figure out what is going on on the machines where you had problems? Kris
        Hide
        npace added a comment -

        Hi Kris,

        Sorry for the delay in responding. Things have been busy lately.

        We never did figure out why this worked on some machines and not others. It's still a problem as of Gradle 1.0M5. Perhaps M6 will fix the issue.

        Thanks.

        Show
        npace added a comment - Hi Kris, Sorry for the delay in responding. Things have been busy lately. We never did figure out why this worked on some machines and not others. It's still a problem as of Gradle 1.0M5. Perhaps M6 will fix the issue. Thanks.
        Hide
        npace added a comment -

        Hi Kris,

        I'm still getting this error. I'm running on Windows 7 and don't have JAVA_HOME set in my environment variables. In eclipse I only have the Java 1.6 JDK installed, not the JRE.

        TOOL VERSIONS:

        Version: Indigo Service Release 1
        Build id: 20110916-0149

        Gradle Tooling Api
        2.9.0.201202032004-SNAPSHOT

        Gradle 1.0-milestone-7

        OUTPUT:

        [sts] -----------------------------------------------------
        [sts] Starting Gradle build for the following tasks:
        [sts] :build
        [sts] -----------------------------------------------------
        :sourcesJar UP-TO-DATE
        :compileJava

        FAILURE: Build failed with an exception.

        • What went wrong:
          Execution failed for task ':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"
        Show
        npace added a comment - Hi Kris, I'm still getting this error. I'm running on Windows 7 and don't have JAVA_HOME set in my environment variables. In eclipse I only have the Java 1.6 JDK installed, not the JRE. TOOL VERSIONS: Version: Indigo Service Release 1 Build id: 20110916-0149 Gradle Tooling Api 2.9.0.201202032004-SNAPSHOT Gradle 1.0-milestone-7 OUTPUT: [sts] ----------------------------------------------------- [sts] Starting Gradle build for the following tasks: [sts] :build [sts] ----------------------------------------------------- :sourcesJar UP-TO-DATE :compileJava FAILURE: Build failed with an exception. What went wrong: Execution failed for task ':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"
        Hide
        Kris De Volder (c) added a comment -

        Yes, I would expect you still have problems with this. There is a solution in the works, but it will require Gradle M8 which is not yet released. See this issue for some more information:
        STS-2276.

        Show
        Kris De Volder (c) added a comment - Yes, I would expect you still have problems with this. There is a solution in the works, but it will require Gradle M8 which is not yet released. See this issue for some more information: STS-2276 .

          People

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

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: