Announcement Announcement Module
No announcement yet.
Upgrade from 2.5.2 to 2.6.0 causes errors with Grails support Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Upgrade from 2.5.2 to 2.6.0 causes errors with Grails support

    I've been using the v2.5.2 of STS with the Grails/Groovy extensions for the last month without major problems. I recently was attempting to install and uninstall Grails plug-ins using the plug-in manager. There were errors which I believed would be resolved by upgrading STS to 2.6.0 (based upon some issues I read in the tracker system). This morning I upgraded my installation of STS from 2.5.2 to 2.6.0. However now I am getting several errors while attempting to work within my existing Grails project.

    First, according to the icon there is an error in the project with /conf/spring/resources.groovy. This is the default file from creating the Grails project. I can open the file and mousing over the error icon in the margin gives the following tooltip:
    Internal compiler error: java.lang.verifyError: (class: org/codehaus/jdt/groovy/internal/compiler/ast/JDTClassNode, method: initialize signature: ()V) Bad access to protected data at org.codehaus.jdt.groovy.internal.compiler.ast.JDTR esolver.createClassNode(

    When I attempt to open any .groovy or .gsp file in the project I'll get an error dialog with the following message:
    An error has occurred. See error log for more details.
    (class: org/codehaus/jdt/groovy/internal/compiler/ast/JDTClassNode, method: initialize signature: ()V) Bad access to protected data

    When I mouse of the "External Tools" button in the tool bar, I'll get an error dialog with the following message:
    An internal error occurred during: "Compute launch button tooltip".
    org.codehaus.groovy.control.SourceUnit.getSource() Lorg/codehaus/groovy/control/io/ReaderSource;

    If I right-click one/any of the files in the project and from the menu chooser Grails Tools -> Refresh dependencies, I'll get an error dialog with the following information:
    Errors occurred during the build.
    Errors running builder 'Java Builder' on project 'MfgMarketplace'.
    (class: org/codehaus/jdt/groovy/internal/compiler/ast/JDTClassNode, method: initialize signature: ()V) Bad access to protected data

    I am able to perform a Grails run-app within STS (telling it to ignore the error in /conf/spring/resources.groovy) and it will start up tomcat and let me use the application. But I'm not able to successfully do much else. Here's the list of installed software (with regards to STS) and version numbers:

    CollabNet Desktop - Eclipse Edition v2.5.0.4
    Grails (production release) v1.3.7
    Groovy-Eclipse Feature v2.1.2-xx-20110310-1500-e26
    Maven Integration for AJDT (Optional) v0.10.0.20100201-0800
    Maven Integration for Eclipse (Required) v0.12.0.20101115-1102
    Maven Integration for WTP (Optional) v0.11.1.20101108-1810
    Project configurators for commonly used maven plugins v0.12.0.20101103-1500
    SpringSource Tool Suite v2.6.0.201103161000-RELEASE
    Springsource Tool Suite Grails Support v2.6.0.201103161000-RELEASE
    Tycho Project Configurators v0.4.3.20101103-1630

    I'm unsure if this is defect that should be reported to the issue tracker, if there is something that I can do to fix this (short of reverting back to the STS v2.5.2), or if more information is needed about this issue.

    If anyone has any ideas or questions, please let me know.

  • #2
    It looks to me like you may be somehow ending up using an incompatible version of the groovy eclipse compiler or JDT patch. Can you check under Window >> Preferences >> Groovy >> Compiler.

    At the bottom of the page there is something saying "You are currently using Groovy Compiler version XXX". What does it say there?

    If its a Groovy 1.6 version, that's probably the problem.

    You could try reinstalling the groovy eclipse plugin as it seems somehow to have gotten messed up.

    You can also try opening the Eclipse plugin registry view. Type "groovy" in the search box. You should see several (probably 2) org.codehaus.groovy plugins. Make sure that the 1.7.8 version is the one that is enabled. You can use the plugin registry to stop/disable and start specific plugins. You will need to restart Eclipse after that.

    The 1.6 plugin isn't really supported anymore. It's there and people who really need 1.6 can try to use it but it won't work well because of too many API differences.

    Normally Eclipse should automatically pick the most recent version of the plugin, but sometimes it can get confused (for unknown reason).

    Let us know how it goes.



    • #3
      I saw the possible compiler issue in a related post but it is correct. In preferences -> Groovy -> Compiler it states "You are currently using Groovy Compiler version 1.7.8.xx-20110310-1500-e36".

      In the Eclipse Plugin Registry it shows both versions of Groovy (1.7 and 1.6). If enabled plugins are denoted by the green arrow on the icon, then it appears it is 1.6 that is enabled and not 1.7.

      STS keeps hanging in this view, it seems the "Initializing the Plug-in Registry View" progress doesn't stop or is having issues. I'm less worried about that.

      Anyhow... I'm about to head out for a series of meetings and seminars. I'll try uninstalling and reinstalling the Groovy plug-in when I get back unless I see a different suggestion on here. Thanks for the help.



      • #4
        Hi Christian,

        Yes, the green arrow is the active plugin. So I'm guessing this *is* the problem. It should be the 1.7 plugin that has the green arrow.



        • #5
          Hi Christian,

          I would recommend upgrading to the latest dev build since we have made changes in that area. This may fix your problem. In particular, we have removed the 1.6 compiler and now optionally let you install the 1.8 compiler

          I am not sure why your STS is choosing the 1.6 instead of 1.7, but this should go away after upgrading. Please use this update site:

          Let me know if this fixes your problem.


          • #6
            I updated to the dev build that Andrew suggested and all seems to be working okay. No errors on the project when it is opened and I am able to open .groovy and .gsp files and edit them. So I'm able to go back to work on the project.

            An somewhat unrelated aside. One of the reasons I did the upgrade was issues I had with the Grails plug-in manager. And I think the upgrade (one or both) may have fixed the initial issue. However, I do see that it still has problems fully deleting a plug-in (RichUI v0.8). It causes an exception attempting to delete one of the files (richui-0.8\lib\commons-codec-1.3.jar). If I attempt to manually delete the plug-in's folder from the .grails/1.3.7/projects/<ProjectName>/plugins directory, I am unable to do so unless I close STS first. Therefore, I'm assuming that the STS opens this particular file and won't let go to uninstall the plug-in. I can manually delete the folder if I close STS first. I haven't tried running the grails plug-in uninstall command with STS closed, but I'm wagering it would work that way. As I said, unrelated to why I started the thread, but a bit related to why I attempted the upgrade.

            Anyhow... thanks for the suggestions and for getting it back working for me.
            Last edited by CBMcArthur; Mar 25th, 2011, 05:37 PM. Reason: Wrong plugin directory. Fixed it.


            • #7
              Glad it is working now.

              I think you are hitting a jar locking problem with windows. See:

              There is a magic system property that you can set. It is still experimental and so we are not advertising it until we are more confident that it works.

              Add this to the command line arguments or to the STS.ini file:
              '-vmargs -Dgreclipse.nonlocking=true'

              And please let us know if this fixes the problem. Once we are more confident that this works (and doesn't cause any odd side effects), we will make this the default.


              • #8

                I ran STS with the command line arguments and was able to uninstall the RichUI plug-in without problems. I assume that it would be best to run STS without that argument unless I have a need to use it to remove a plug-in. Or are ya'll looking for people to run it and see if anything blows up?


                • #9
                  We are fairly certain that this option causes no problems. The option that you turned on enables a non-locking classloader for Groovy instead of a standard classloader. We've already had some good feedback on it and so it's highly likely that this will become the default starting 2.7.0. Thanks for the feedback. This is another datapoint that shows that the classloader is working.


                  • #10
                    I hit the same problem and I solved it by manually deleting the 1.6x version of groovy from the plugins folder of STS.

                    I have no idea why STS installs both the 1.7 and the 1.6 version of groovy although it claims to use only the 1.7 version in it's compiler as is evidenced in the property pages.