Announcement Announcement Module
Collapse
No announcement yet.
STS 2.8.0.M1 released Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • STS 2.8.0.M1 released

    Dear Spring Community,

    I am happy to announce the newest milestone release 2.8.0.M1 of the SpringSource Tool Suite (STS).

    This milestone brings mostly some updates and new features for Groovy&Grails developers, including:
    • update to tc Server Developer Edition 2.5.1
    • update to Maven 3.0.3
    • update to Mylyn 3.6.1
    • runs on JDK 1.7.0, including Spring Roo 1.1.5
    • validation and quick-fixes for constructor-arg
    • support for Grails 2.0.0.M1
    • enhanced DSL support for Grails 2.0.0.M1
    • lot of improvements for Groovy-Eclipse
    More details can be found in the New and Noteworthy document.

    As always downloads are available from the STS download page.

    2.8.0.M2 is planned for the second half of September, followed by the 2.8.0 GA in mid October 2011. 2.8.0.M2 will also include advanced support for Spring 3.1.

    Regards,
    Martin

  • #2
    Can you tell me what the bookmarks url is for updating.
    I was before in a night snapshot http://dist.springsource.com/snapsho.../bookmarks.xml
    In the announcement http://www.springsource.org/node/3204, the instructions are pointing to the 2.7.1 release.

    Comment


    • #3
      Hey!

      There is a section called "Installing from the Milestone Update Site" in the install documentation that also contains the link to the right bookmarks.xml file:
      http://dist.springsource.com/milesto.../bookmarks.xml

      HTH,
      Martin

      Comment


      • #4
        Hello,

        I'm using STS 2.8.0M1.

        When I try to upgrade a project from Grails 1.3 to 2.0 and I get the following error:
        Code:
        | Error Error installing plugin: Unable to delete file C:\Documents and Settings\Pathfinder\.grails\2.0.0.M1\projects
        \ExtConfigTest\plugins\tomcat-1.3.7\lib\catalina-ant.jar (Use --stacktrace to see the full trace)
        If I run the command "upgrade --stacktrace", I am prompted to answer "y or n" but the console won't accept any input. Here is the output:
        Code:
         WARNING: This target will upgrade an older Grails application to 2.0.0.M1.
                Are you sure you want to continue?
        Invalid input. Must be one of [y,n] > Invalid input. Must be one of [y,n] > Invalid input. Must be one of [y,n] >  .....
        This prompt repeats many times before the command is terminated.
        Last edited by ohiomoto; Aug 15th, 2011, 10:41 AM.

        Comment


        • #5
          Hi ohiomoto,

          You seem to have hit two serious bugs at once... one is known: http://jira.codehaus.org/browse/GRECLIPSE-994
          This is a known issue on Windows, caused by Java class loaders locking jar files. See the bugreport for a workaround
          (summary you can add a line to your STS.ini file to define the system property "-Dgreclipse.nonlocking=true".

          The reason why this option is not on by default is that it is a bit experimenal and also greatly affects performance of the classloader.

          The second bug is a new one and quite a serious one as well. I raised a Jira issue here:
          https://issuetracker.springsource.com/browse/STS-2017

          I've already committed a fix but you will have to update from the nightly update after the next nightly build to get the fix.
          It is probably easier for you to simply use one of the following workarounds.

          Workaround 1:
          add -non-interactive as an option to your command (this will suppress the question that is misbehaving).

          Workaround 2 (preferred):
          Open the preferences at "Windows >> Preferences >> Groovy >> Grails >> Grails Launch"
          There, add a system property
          name of property: jline.terminal
          value of property: jline.UnsupportedTerminal

          Comment


          • #6
            grails in-place plugin resolution/dependencies/build-path entries not working?

            grails in-place plugin resolution via the grails.plugin.location.XYZ directive in BuildConfig.groovy seems to be not working in 2.8.0.m1 ... for me, the plugin source folders do not get added to the projects' build path after invoking grails tools --> refresh dependencies.

            my BuildConfig.groovy entry looks like these (tried both, none working)
            grails.plugin.location.myplugin = myplugin-in-a-subdir/myplugin-1.2.3
            grails.plugin.location.myplugin = ../myplugin-1.2.3

            can someone confirm this or tell me its working for him/her?

            zyro

            Comment


            • #7
              Thanks Kris. The second workaround is working, but I'm still stuck on the first.

              Originally posted by Kris De Volder View Post
              You seem to have hit two serious bugs at once... one is known: http://jira.codehaus.org/browse/GRECLIPSE-994
              This is a known issue on Windows, caused by Java class loaders locking jar files. See the bugreport for a workaround
              (summary you can add a line to your STS.ini file to define the system property "-Dgreclipse.nonlocking=true".
              I added "-Dgreclipse.nonlocking=true" to end of my STS.ini file but still can't upgrade the project. Here is my output:
              Code:
               ...
              Environment set to development.....
              > 
                      WARNING: This target will upgrade an older Grails application to 2.0.0.M1.
                      Are you sure you want to continue?
                                 [y,n] y
              | Installing zip grails-hibernate-2.0.0.M1.zip...
              | Installing zip grails-hibernate-2.0.0.M1.zip....
              | Installing zip grails-hibernate-2.0.0.M1.zip.....
              | Installed plugin hibernate-2.0.0.M1
              | Resolving plugin JAR dependencies
              | Resolving plugin JAR dependencies.
              | Resolving plugin JAR dependencies..
              | Resolving plugin JAR dependencies...
              > You currently already have a version of the plugin installed [tomcat-1.3.7]. Do you want to update to [tomcat-2.0.0.M1]? [y,n] > Invalid input. Must be one of [y,n] y
              | Error Error installing plugin: Unable to delete file C:\Documents and Settings\Pathfinder\.grails\2.0.0.M1\projects\ExtConfigTest\plugins\tomcat-1.3.7\lib\catalina-ant.jar
              : Unable to delete file C:\Documents and Settings\Pathfinder\.grails\2.0.0.M1\projects\ExtConfigTest\plugins\tomcat-1.3.7\lib\catalina-ant.jar
              	at org.apache.tools.ant.taskdefs.Delete.handle(Delete.java:704)
              	at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:753)
              	at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:749)
              	at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:571)
              	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
              	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
              	at _PluginDependencies_groovy$_run_closure13_closure28.doCall(_PluginDependencies_groovy:330)
              	at _PluginDependencies_groovy.withPluginInstall(_PluginDependencies_groovy:353)
              	at _PluginDependencies_groovy$_run_closure13.doCall(_PluginDependencies_groovy:328)
              	at _GrailsPlugins_groovy$_run_closure2.doCall(_GrailsPlugins_groovy:59)
              	at Upgrade$_run_closure1.doCall(Upgrade.groovy:218)
              	at Upgrade$_run_closure2.doCall(Upgrade.groovy:226)
              | Error Error installing plugin: Unable to delete file C:\Documents and Settings\Pathfinder\.grails\2.0.0.M1\projects\ExtConfigTest\plugins\tomcat-1.3.7\lib\catalina-ant.jar

              Tim

              Comment


              • #8
                Hi Ohiomoto (Tim),

                Can you double check your STS.ini. Make sure to put the -D... on a separate line and after -vmargs. (The format of the STS.ini file is rather finicky and position of newlines do matter).

                If that doesn't work, also, try closing all the groovy editors in STS. It is classloaders that are kept open by the editors that might be holding on to locks. Closing the editors may be needed to release the locks.

                If somehow the nonlocking classloader is really not working for you (not sure why??).

                A last resort is to close STS this will release the locks for sure even without the non-locking loader. Then run the command that is giving you trouble from the commandline.

                However... the non locking classloader should work.

                Comment


                • #9
                  Zyro...

                  What version of Grails are you using? Do you have small sample project that has the problem? I can have a look at it see if I can reproduce the problem. But I need a bit more info from you.

                  Anyway, I'll play a bit with 'inline plugins' myself to make sure its still working for me :-)

                  For problems like this, consider raising a Jira bugtracker issue...
                  https://issuetracker.springsource.com/browse/STS

                  It is more convenient to track progress on a suspected bug in focussed bug tracker issue than burrying your question inside a '2.8.0.m1' releases thread on the forum. Or... at least start a new thread with your question (if signing on to the jira tracker is too much hassle).

                  Comment


                  • #10
                    Zyro,

                    A bit of info on 'inline plugins'. Perhaps it is actually working for you. If your inline plugin is a project in the same workspace, you are not supposed to get the source folders in the same way that you get them for 'normal' plugins. Instead the plugin dependency will be represented in STS as a direct project dependency between the two projects. That means that the project that uses the plugin will have the plugin project on its classpath. This means it will be able to use the compiled .class files from the plugin project instead of having its source folders be linked into the project.

                    Kris

                    Comment


                    • #11
                      Here is the contents of my STS.ini:
                      Code:
                      -vm
                      C:/Program Files/Java/jdk1.6.0_21/bin/javaw.exe
                      -startup
                      plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
                      --launcher.library
                      plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.100.v20110502
                      -product
                      com.springsource.sts.ide
                      --launcher.defaultAction
                      openFile
                      --launcher.XXMaxPermSize
                      384M
                      -vmargs
                      -Dgreclipse.nonlocking=true
                      -Dosgi.requiredJavaVersion=1.5
                      -Xmn128m
                      -Xms256m
                      -Xmx768m
                      -Xss1m
                      -XX:PermSize=128m
                      -XX:MaxPermSize=384m
                      Closing the editor windows didn't help either. I've also restarted STS with no luck.

                      I tried switching to Groovy 1.7 compiler and that didn't help either.

                      I've never tried to run Grails from the cmd line in Windows here at work. I've only done it on my personal laptops using Linux (I don't use Windows at home). I'm not sure how/where to do it in Windows.

                      One last idea. I still have STS 2.7.1 installed in the same springsource directory as STS 2.8. Any chance the 2.7 STS.ini might be getting hooked into STS 2.8? Seems far fetched too me, but what do I know.

                      Comment


                      • #12
                        Interesting. I would say that if closing STS didn't release the lock, it must be another process that's responsible for locking the jar. Shutting down the JVM that loaded the jar will definietly release any locks that JVM was holding. Note that this lock thing you are hitting is actually a JVM problem. It could be any Java process that has opened a classloader on that particular jar file. Can you think of any other Java processes on your machine that might want to load classes from that jar (maybe a tomcat server process).

                        Of course, if you restart STS, and the non-locking loader is not working for you, it might be locking the jar again very quickly...

                        The only way to know for sure is *not* restart STS and run the upgrade command on the command line.
                        Last edited by Kris De Volder; Aug 16th, 2011, 01:39 PM.

                        Comment


                        • #13
                          I don't think you could be loading the wrong .ini file. But if you want to make sure, try put something in the ini file that would make it crash, like maybe point the -vm to a non-existent location.

                          Comment


                          • #14
                            No. But I haven't tried the command with STS closed yet. I've only restarted it. I'm trying to find my project directory in cmd.exe right now. (I'm having problems with the "ls -l" command though. LOL)

                            Comment


                            • #15
                              Originally posted by Kris De Volder View Post
                              Of course, if you restart STS, and the non-locking loader is not working for you, it might be locking the jar again very quickly...

                              The only way to know for sure is *not* restart STS and run the upgrade command on the command line.
                              Okay, I was able run the upgrade command form the command line and it still throws the same error. Could subversion have it's hooks in that file?

                              Comment

                              Working...
                              X