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

STS should allow more parameters for Gradle builds / task execution to be controlled via the task UI (JRE home, system properties, environment parameters, Java options ...)

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 2.8.0.RELEASE
    • Fix Version/s: 3.0.0.M2
    • Component/s: GRADLE
    • Labels:
      None

      Description

      I don't know how hard it would be, but I miss the possibility to run Gradle in a different JRE when configuring a Gradle Build launch configuration, just like it is possible with an Ant Build.

      Benefits:

      • the possibility to specify the JRE to use (see "JRE" tab of an Ant Build launch configuration)
      • the possibility to compose the classpath for the Gradle build script (see "Classpath" tab of an Ant Build launch configuration)
      • (most important) the possibility to set environment variables (see "Environment" tab of an Ant Build launch configuration) to be made available to Gradle when running the build script

      The last thing would be extremely useful to me: in fact, right now the Gradle daemon says that I have no JAVA_HOME set (because I haven't this environment variable set at the OS level) so if I run a Gradle task that needs to compile Java code from Eclipse, I get an error because a JDK cannot be found. So, I'm forced to set this environment variable at the OS level or at least to make it available to the whole Eclipse IDE, with possible side effects on other components that may use that environment variable value.

        Activity

        Hide
        Kris De Volder (c) added a comment -

        Gradle always runs in a separate JRE since it uses the Gradle Daemon, which is a separate process from STS.

        Being able to specify the things you mention may still be useful, but probably should be treated as different issues. Some comments
        e

        • the possibility to specify the JRE to use (see "JRE" tab of an Ant Build launch configuration)
          Could be useful. This requires a tooling API extension.
          I've added a comment about specifying JRE/JDK home to http://issues.gradle.org/browse/GRADLE-1691
        • the possibility to compose the classpath for the Gradle build script (see "Classpath" tab of an Ant Build launch configuration)
          => Aren't you supposed to use gradle itself to declare your build scripts dependencies? Won't that factor into the build scripts classpath? If so, why would you need to be able to specify that in the running UI (possibly making the IDE behave differently from the commandline because the classpaths are different).
        • (most important) the possibility to set environment variables (see "Environment" tab of an Ant Build launch configuration) to be made available to Gradle when running the build script
          Also added a note to http://issues.gradle.org/browse/GRADLE-1691
        Show
        Kris De Volder (c) added a comment - Gradle always runs in a separate JRE since it uses the Gradle Daemon, which is a separate process from STS. Being able to specify the things you mention may still be useful, but probably should be treated as different issues. Some comments e the possibility to specify the JRE to use (see "JRE" tab of an Ant Build launch configuration) Could be useful. This requires a tooling API extension. I've added a comment about specifying JRE/JDK home to http://issues.gradle.org/browse/GRADLE-1691 the possibility to compose the classpath for the Gradle build script (see "Classpath" tab of an Ant Build launch configuration) => Aren't you supposed to use gradle itself to declare your build scripts dependencies? Won't that factor into the build scripts classpath? If so, why would you need to be able to specify that in the running UI (possibly making the IDE behave differently from the commandline because the classpaths are different). (most important) the possibility to set environment variables (see "Environment" tab of an Ant Build launch configuration) to be made available to Gradle when running the build script Also added a note to http://issues.gradle.org/browse/GRADLE-1691
        Hide
        Kris De Volder (c) added a comment -
        Show
        Kris De Volder (c) added a comment - Blocked by http://issues.gradle.org/browse/GRADLE-1691
        Hide
        Kris De Volder (c) added a comment -

        I reworded the issue title to be more about being able to specify parameters for task execution than about being running in a separate VM.

        Show
        Kris De Volder (c) added a comment - I reworded the issue title to be more about being able to specify parameters for task execution than about being running in a separate VM.
        Hide
        Mauro Molinari added a comment -

        Hi Kris, thank you for your feedback and for changing this issue title.

        Regarding point n.2, it is the less important actually. If the gradle command-line tool also allowed to specify additional classpath entries, that tab could mimic that parameter... however, issuing a gradle --help it seems like there's no such option.

        So you may ignore point n.2 or give it the lowest priority over my enhancement request.

        Show
        Mauro Molinari added a comment - Hi Kris, thank you for your feedback and for changing this issue title. Regarding point n.2, it is the less important actually. If the gradle command-line tool also allowed to specify additional classpath entries, that tab could mimic that parameter... however, issuing a gradle --help it seems like there's no such option. So you may ignore point n.2 or give it the lowest priority over my enhancement request.
        Hide
        Davide Cavestro added a comment -

        We'd also need to specify additional gradle launch parameters, such as --info or --profile and so on

        Show
        Davide Cavestro added a comment - We'd also need to specify additional gradle launch parameters , such as --info or --profile and so on
        Hide
        Mauro Molinari added a comment -

        Just an addition: if STS allowed to specify a JRE for Gradle, it would be extremely useful if that JRE (which in most cases is a JDK, since you use it to develop within Eclipse) could be made recognized by the Gradle Daemon as the one to use to find javac... This would avoid the need to specify a JAVA_HOME environment property just to make Gradle find javac, which is very annoying for me since in Windows I have to set that environment variable system wide (at least for the current user) or to change the shortcut to run Eclipse, which now is against eclipse.exe itself, so that it is against a batch file that sets that variable for the Eclipse session.and then run eclipse.exe...

        Show
        Mauro Molinari added a comment - Just an addition: if STS allowed to specify a JRE for Gradle, it would be extremely useful if that JRE (which in most cases is a JDK, since you use it to develop within Eclipse) could be made recognized by the Gradle Daemon as the one to use to find javac... This would avoid the need to specify a JAVA_HOME environment property just to make Gradle find javac, which is very annoying for me since in Windows I have to set that environment variable system wide (at least for the current user) or to change the shortcut to run Eclipse, which now is against eclipse.exe itself, so that it is against a batch file that sets that variable for the Eclipse session.and then run eclipse.exe...
        Hide
        Kris De Volder (c) added a comment -

        Right, if Gradle tooling API allows caller to specify a Java home, in whatever way (environment parameter or a specific option just for setting Java home, then the right thing for STS to do would be to take the Java home from some preference specified either at the workspace level or project level.

        BTW: Also found this issue which relates specifically to setting the Java home:
        http://issues.gradle.org/browse/GRADLE-1852

        Show
        Kris De Volder (c) added a comment - Right, if Gradle tooling API allows caller to specify a Java home, in whatever way (environment parameter or a specific option just for setting Java home, then the right thing for STS to do would be to take the Java home from some preference specified either at the workspace level or project level. BTW: Also found this issue which relates specifically to setting the Java home: http://issues.gradle.org/browse/GRADLE-1852
        Hide
        Kris De Volder (c) added a comment -

        Actually, I think most if not all of what you are asking for is possible since now since 3.0.0.M2 (but I guess I just forgot to close the issue when I did the work).

        In M2 you can now configure Java_HOME and commandline options to pass to Gradle in both a Global preferences page and individual launch configurations.

        So I'll close it now.

        If you are still finding that there are things that you can't do, or have suggestions on how to improve it further, please don't hesitate to open other issues / bugs/ feature requests.

        Show
        Kris De Volder (c) added a comment - Actually, I think most if not all of what you are asking for is possible since now since 3.0.0.M2 (but I guess I just forgot to close the issue when I did the work). In M2 you can now configure Java_HOME and commandline options to pass to Gradle in both a Global preferences page and individual launch configurations. So I'll close it now. If you are still finding that there are things that you can't do, or have suggestions on how to improve it further, please don't hesitate to open other issues / bugs/ feature requests.
        Hide
        Mauro Molinari added a comment - - edited

        Hi Kris,
        actually I can't find the possibility to select the JRE in the launch configuration in STS 3.1.0: I can just add JVM/program args. I can't find the possibility to set environment variables either.
        Moreover, another option which is present for Ant builds could be useful: a checkbox to choose whether the project must be built before launching or not (see the "Build" tab for Ant launch configurations). Right now, build before launching is always on. There are (many, if not all) cases in which I don't need the project to be built in Eclipse before launching the Gradle build script, so it would be better not having to wait for a project build to complete if not necessary.

        Show
        Mauro Molinari added a comment - - edited Hi Kris, actually I can't find the possibility to select the JRE in the launch configuration in STS 3.1.0: I can just add JVM/program args. I can't find the possibility to set environment variables either. Moreover, another option which is present for Ant builds could be useful: a checkbox to choose whether the project must be built before launching or not (see the "Build" tab for Ant launch configurations). Right now, build before launching is always on. There are (many, if not all) cases in which I don't need the project to be built in Eclipse before launching the Gradle build script, so it would be better not having to wait for a project build to complete if not necessary.
        Hide
        Kris De Volder (c) added a comment -

        All good points. But I don't want to reopen this issue. Would you mind creating separate smaller issues?

        I would have to investigate and implement each separately. I don't even know, at the moment, if it is posible to set env variables via the tooling API. So some of what you are asking here is probably implementable today, but other bits may not be. That's a good reason to split things up.

        Show
        Kris De Volder (c) added a comment - All good points. But I don't want to reopen this issue. Would you mind creating separate smaller issues? I would have to investigate and implement each separately. I don't even know, at the moment, if it is posible to set env variables via the tooling API. So some of what you are asking here is probably implementable today, but other bits may not be. That's a good reason to split things up.
        Hide
        Mauro Molinari added a comment -

        Hi Kris, I opened STS-2998, STS-2999 and STS-3000 (yeah, I won the issue number 3000! :-D).

        Show
        Mauro Molinari added a comment - Hi Kris, I opened STS-2998 , STS-2999 and STS-3000 (yeah, I won the issue number 3000! :-D).
        Hide
        Kris De Volder (c) added a comment -

        Thanks!

        Show
        Kris De Volder (c) added a comment - Thanks!

          People

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

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: