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

Classpath problems when importing existing Grails projects

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.5.1.RELEASE
    • Fix Version/s: 2.5.2.RELEASE
    • Component/s: GRAILS
    • Labels:
      None
    • Environment:

      Win7 64-bit, JDK 1.6.0_21

      Description

      For the SpringSource Groovy & Grails course I've created several Grails projects as part of the labs. When these labs are imported in a new workspace (by the workspace builder plugin that Christian created, but I don't think that's relevant in this case) none of the Grails projects show a Grails Classpath Container, even though it's specified in the .classpath files. BTW, the workspace auto-configures a Grails 1.3.5 installation from a sibling directory of the STS install dir: I'm not sure if that happens before or after the projects are imported and if that might be part of the problem.
      I can fix this problem by doing a Grails Tools -> Refresh Dependencies for each project: after that, the Grails Classpath Container shows up with all of the expected dependencies. However, the projects will still have compilation errors stating that GroovyObject is not on the classpath, even though it is (the groovy jar is contained in the Grails Classpath Container). Cleaning the projects, doing a fake edit or closing and opening the projects doesn't seem to solve this issue: I have to restart the workspace to get rid of these errors. After that everything looks good.

      So basically there are two issues, the missing classpath container and the compilation error after the container has been added. I don't know if they are related; the latter issue might even be a GRECLIPSE issue, but I'm reporting it here for now.
      If this issue is not related to the workspace builder plugin, would it be an option to automatically run the Refresh Dependencies task for newly imported Grails projects? Right now the workspace is full of errors and requires a lot of manual fixing to become error-free.

      I've attached the labs which will hopefully allow you to reproduce the issue.

        Activity

        Hide
        Andy Clement (c) added a comment -

        Yep, I get the same thing - just doing a regular project import for those attached projects. Groovy ones are ok, grails ones are in a mess. I can avoid the restart to address the second part of the problem if I right click Groovy>Add libs - but that isn't really the right solution! just a hack around the problem.

        Show
        Andy Clement (c) added a comment - Yep, I get the same thing - just doing a regular project import for those attached projects. Groovy ones are ok, grails ones are in a mess. I can avoid the restart to address the second part of the problem if I right click Groovy>Add libs - but that isn't really the right solution! just a hack around the problem.
        Hide
        Kris De Volder (c) added a comment -

        I have tried to import the provided zip and can also recreate the problem. That is great, since it means I can have a go at debugging why this is happening.

        Show
        Kris De Volder (c) added a comment - I have tried to import the provided zip and can also recreate the problem. That is great, since it means I can have a go at debugging why this is happening.
        Hide
        Kris De Volder (c) added a comment -

        I think both problems are related. I think JDT is caching the result of resolving the classpath, and the problem is that it caches a resolved classpath from before the class path container was initialized.

        It looks like then... refresh dependencies fixed the CP container, but, JDT doesn't refresh its cached copy of the classpath. Apparantly this cache is quite persistent, it sticks around as long as nothing is changed to the raw classpath. Refrshing the dependencies in this case doesn't change the raw classpath, it only changes what the raw cp container resolves to.

        Show
        Kris De Volder (c) added a comment - I think both problems are related. I think JDT is caching the result of resolving the classpath, and the problem is that it caches a resolved classpath from before the class path container was initialized. It looks like then... refresh dependencies fixed the CP container, but, JDT doesn't refresh its cached copy of the classpath. Apparantly this cache is quite persistent, it sticks around as long as nothing is changed to the raw classpath. Refrshing the dependencies in this case doesn't change the raw classpath, it only changes what the raw cp container resolves to.
        Hide
        Kris De Volder (c) added a comment -

        Workaround: refresh dependencies and then disable and re-enable dependency management makes compile errors go away. It forces JDT to flush its cached resolved classpath.

        Show
        Kris De Volder (c) added a comment - Workaround: refresh dependencies and then disable and re-enable dependency management makes compile errors go away. It forces JDT to flush its cached resolved classpath.
        Hide
        Kris De Volder (c) added a comment -

        I forced a "setRawClassPath" in refresh dependencies, even if rawclasspath is not changed. This fixes issue "2". I.e. when doing refresh dependencies the compile errors will disappear.

        It doesn't yet fix the issue that on initial import JDT will end up trying to immediately resolved the classpath, before we've had a chance to compute the dependency data.

        To fix this issue we need to somehow get refresh dependencies to run on the imported project.

        Show
        Kris De Volder (c) added a comment - I forced a "setRawClassPath" in refresh dependencies, even if rawclasspath is not changed. This fixes issue "2". I.e. when doing refresh dependencies the compile errors will disappear. It doesn't yet fix the issue that on initial import JDT will end up trying to immediately resolved the classpath, before we've had a chance to compute the dependency data. To fix this issue we need to somehow get refresh dependencies to run on the imported project.
        Hide
        Kris De Volder (c) added a comment -

        Fix is committed.

        Show
        Kris De Volder (c) added a comment - Fix is committed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Joris Kuipers
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: