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

Please tie Groovy compiler version to workspace

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 2.8.0.M1
    • Component/s: GRAILS
    • Labels:
    • Environment:

      STS 2.7.0.M2, Groovy Eclipse Nightly

      Description

      At the moment, I have one workspace for Groovy 1.8 and one for Groovy 1.7. Unfortunately, when I switch between the two, not only do I have to wait for STS to restart with the new workspace, but I also have to change the Groovy compiler version and restart. That's 2 restarts every time I want to switch between Groovy versions.

      Perhaps I should use working sets for this?

      Another issue I have is that when I install updates, STS switches to Groovy 1.8 again, which isn't much good when I'm working on a Groovy 1.7/Grails 1.3 project.

        Activity

        Hide
        Andy Clement (c) added a comment -

        more of a groovy-eclipse issue, really, but we can address it here. Andrew, didn't some guy write a blog article on setting things up like that (i.e. tying the version to the workspace rather than the installation?) - can we learn from that and do something differently in our switching?

        Show
        Andy Clement (c) added a comment - more of a groovy-eclipse issue, really, but we can address it here. Andrew, didn't some guy write a blog article on setting things up like that (i.e. tying the version to the workspace rather than the installation?) - can we learn from that and do something differently in our switching?
        Andy Clement (c) made changes -
        Field Original Value New Value
        Assignee Andrew Eisenberg [ aeisenberg ]
        Andy Clement (c) made changes -
        Component/s GRAILS [ 10250 ]
        Hide
        Andrew Eisenberg (c) added a comment -

        Here are the instructions to having 2 different workspaces with 2 different compiler versions. Doing things this way should address both of your problems (I haven't tried this out myself, but it looks like it should work).

        http://en.appsatori.eu/2011/05/easy-switching-between-groovy-eclipse.html

        Essentially, you need to specify different Eclipse/STS configuration areas for each instance of the compiler you want to run.

        Unfortunately, I can't think of a way to easily automate this approach. We might be able to provide a shell script that users can run after installing STS (I think that STS must have been launched at least once before this approach can work). This needs a little more thought before I try to really fix this problem.

        Show
        Andrew Eisenberg (c) added a comment - Here are the instructions to having 2 different workspaces with 2 different compiler versions. Doing things this way should address both of your problems (I haven't tried this out myself, but it looks like it should work). http://en.appsatori.eu/2011/05/easy-switching-between-groovy-eclipse.html Essentially, you need to specify different Eclipse/STS configuration areas for each instance of the compiler you want to run. Unfortunately, I can't think of a way to easily automate this approach. We might be able to provide a shell script that users can run after installing STS (I think that STS must have been launched at least once before this approach can work). This needs a little more thought before I try to really fix this problem.
        Hide
        Andrew Eisenberg (c) added a comment -

        The problem is that we can't use standard Eclipse preferences to determine which groovy compiler to use since by the time that we have access to Eclipse preferences, the compiler has already been chosen, so we need a different way to choose the compiler, a way that starts much earlier.

        So, here are 2 ideas, neither of which I know much about, but are worth exploring:

        1. framework adapter hooks — allow us to hook into the OSGi runtime at an early enough time to choose the proper compiler bundle. There would still be the problem of ensuring that the 1.8 bundle never starts, and also we'd need to figure out where to store this information.
        2. auto-starting a bundle — allows a bundle to start very early in the OSGi startup. Similar issues as above.
        Show
        Andrew Eisenberg (c) added a comment - The problem is that we can't use standard Eclipse preferences to determine which groovy compiler to use since by the time that we have access to Eclipse preferences, the compiler has already been chosen, so we need a different way to choose the compiler, a way that starts much earlier. So, here are 2 ideas, neither of which I know much about, but are worth exploring: framework adapter hooks — allow us to hook into the OSGi runtime at an early enough time to choose the proper compiler bundle. There would still be the problem of ensuring that the 1.8 bundle never starts, and also we'd need to figure out where to store this information. auto-starting a bundle — allows a bundle to start very early in the OSGi startup. Similar issues as above.
        Hide
        Peter Ledbrook added a comment -

        Thanks for the workaround. Since that's available, you could drop the priority to minor.

        Show
        Peter Ledbrook added a comment - Thanks for the workaround. Since that's available, you could drop the priority to minor.
        Hide
        Andrew Eisenberg (c) added a comment -

        I'll keep the priority as major so that it doesn't fall off our radar when we start doing our planning post 2.7.0.

        Show
        Andrew Eisenberg (c) added a comment - I'll keep the priority as major so that it doesn't fall off our radar when we start doing our planning post 2.7.0.
        Hide
        Andrew Eisenberg (c) added a comment -

        I have been playing around with option 1 above. I have implemented a framework adapter hook that allows users to control which groovy version starts based on a system property passed into STS. So, the idea is to specify this either on the command line or in the STS.ini file:

        -Dgroovy.compiler.level=18
        

        or

        -Dgroovy.compiler.level=17
        

        (Leaving out the system property will ensure that things continue to behave as before.)

        This is working for me in my runtime workspace, but I have no idea if this will work in a real workspace. I pushed out the changes so that we can get a build of this going and test it outside of a dev environment.

        Peter, I wouldn't recommend trying this out yet. But, this does give us something to play with.

        Show
        Andrew Eisenberg (c) added a comment - I have been playing around with option 1 above. I have implemented a framework adapter hook that allows users to control which groovy version starts based on a system property passed into STS. So, the idea is to specify this either on the command line or in the STS.ini file: -Dgroovy.compiler.level=18 or -Dgroovy.compiler.level=17 (Leaving out the system property will ensure that things continue to behave as before.) This is working for me in my runtime workspace, but I have no idea if this will work in a real workspace. I pushed out the changes so that we can get a build of this going and test it outside of a dev environment. Peter, I wouldn't recommend trying this out yet. But, this does give us something to play with.
        Hide
        Andrew Eisenberg (c) added a comment -

        OK Peter, could you try this out to see if it works:

        1. Install the latest and greatest Groovy-Eclipse from the dev update site:
          http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/
          http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/
        2. start STS from the command line and add -vmargs -Dgroovy.compiler.level=18 to start an instance of STS that uses the groovy 1.8 compiler
        3. Start another instance and add this to the command line -vmargs -Dgroovy.compiler.level=17.

        Make sure that you can run both of them at the same time.

        Please let me know if this is working for you. I was able to do this locally, but my experience with mucking around with OSGi in Eclipse is that it is very finicky and hard to test in all environments. Once I hear from you that it works, I'll make a wider announcement of this.

        Show
        Andrew Eisenberg (c) added a comment - OK Peter, could you try this out to see if it works: Install the latest and greatest Groovy-Eclipse from the dev update site: http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/ http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/ start STS from the command line and add -vmargs -Dgroovy.compiler.level=18 to start an instance of STS that uses the groovy 1.8 compiler Start another instance and add this to the command line -vmargs -Dgroovy.compiler.level=17 . Make sure that you can run both of them at the same time. Please let me know if this is working for you. I was able to do this locally, but my experience with mucking around with OSGi in Eclipse is that it is very finicky and hard to test in all environments. Once I hear from you that it works, I'll make a wider announcement of this.
        Hide
        Andrew Eisenberg (c) added a comment -

        Resolving this issue now. This has now been tested by multiple users and there is confirmation that it is working.

        However, there is a caveat. Specifying the -vmargs on the command line will override the vmargs in the eclipse.ini/STS.ini. All vmargs from these files must be explicitly added to the command line so that they will not be ignored.

        Show
        Andrew Eisenberg (c) added a comment - Resolving this issue now. This has now been tested by multiple users and there is confirmation that it is working. However, there is a caveat. Specifying the -vmargs on the command line will override the vmargs in the eclipse.ini/STS.ini. All vmargs from these files must be explicitly added to the command line so that they will not be ignored.
        Andrew Eisenberg (c) made changes -
        Fix Version/s 2.8.0.M1 [ 11184 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Complete [ 13 ]
        Andrew Eisenberg (c) made changes -
        Labels groovy
        Trevor Marshall (c) made changes -
        Workflow jira [ 33434 ] jira with Pivotal Tracker [ 66444 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        48d 9h 42m 1 Andrew Eisenberg (c) 03/Aug/11 3:46 PM

          People

          • Assignee:
            Andrew Eisenberg (c)
            Reporter:
            Peter Ledbrook
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: