Announcement Announcement Module
No announcement yet.
STS complains about missing classes Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • STS complains about missing classes

    I am using STS 2.6.1 to build a grails application. After I updated the application to grails 1.3.7 (from the command line) an updated the spring security core & spring security acl plugins, the IDE started complaining that it cannot find classes such as
    grails.plugins.springsecurity.acl.AbstractAclObjec tIdentity

    I made sure that the IDE is pointing to Grails 1.3.7.

    I tried restarting the IDE, but that didn't help.
    I tried cleaning the project, but that didn't help.
    I tried deleting the project and re-adding it to the workspace, but that didn't help.

    Despite the alleged compilation errors, the application builds and runs fine. It also runs without complaining from the shell command line.

    I am wondering if there is some compiled cache somewhere that's not being cleared.

    What should I try next to get the errors to go away?



  • #2
    More info: I created a new workspace, and re-imported the source code from SVN. STS still complains about compilation errors even though the code runs fine. Specifically, it thinks I have multiply-defined domain classes that were generated by the Spring Security ACL plugin in Grails. Clean has no effect on the errors. Is there a way to tell where it thinks the duplicates are? I saw nothing obviously wrong with the .classpath file.


    • #3
      Have you tried running refresh dependencies? CTRL+G R when inside the Grails perspective.

      It sounds like classpath confusion. Refresh dependencies will rebuild the classpath and it is required whenever you make structural changes to your project from outside of STS.


      • #4
        Thanks for your response, Andrew. I refreshed dependencies as you suggested, but the compiler still complains about the classes being already defined. I did a grails clean just in case as well. I can run the code just fine, however.


        • #5
          I did refresh dependencies, but that did not help.


          • #6
            You mentioned that it complains about duplicate classes. Can you provide more info? Have you tried finding the classes? What are their names and packages, and where are they precisely
            w.r.t to your project structure? If you have the name of a class you can try to find (copies of) it by using the "open type" function (press CTRL-SHIFT-T).

            One possible explanation is that there may in fact be duplicate classes that exist in different source folders. If so, that is a known problem in Eclipse/STS.
            Eclipse doesn't allow duplicate classes because it compiles all source folders in a project together. With commandline tools (grails in specific) they compile
            the source folders separately and so don't experience this limitation. Not sure this is the problem, but it is a possibility.

            You seem to be having a lot of problems with Spring Security ACL plugin in STS (I recall a prior issue which is logged here:
            Could be there is something unusual about the plugin that triggers some bugs in STS.

            I'll play around with it a bit myself and see if I can reproduce some of these problems. Keep an eye on the STS-1792 issue, I'll follow up there if I find something.


            • #7
              Hi Kris,

              Thanks for the info. There were indeed two copies of the classes created by the Spring Security ACL plugin. In addition to the correct place (in the grails-app/domain location) there was another copy in a directory called .link_to_grails_plugins/... in the project directory. Does that folder need to be in the class path?


              • #8
                Hi Gene, I played with it a little bit discovered some things.

                First, the sample app is broken in Grails 1.3.7 because of this issue:

                That's a Grails issue and it has been fixed. But the sample app uses an older, broken with Grails 1.3.7 version of the ACL plugin.
                I used the Grails plugin manager in STS to upgrade the spring-security-core and spring-security-acl plugins and that seemed to fix that problem.

                I also ran commands to create these domain classes as explained in the tutorial (I'm not sure you really need to do this, but just in case :-)

                The next problem I get is exactly like you describe: duplicate classes and it is because there is two copies of the classes that acl plugin *copied* into your
                project. You have both the original and the copied one. The tutorial explain why they do this copying, but unfortunately it creates problems in STS.

                To answer your question, does that "link-to..." entry need to be in the classpath... yes and no!

                Yes, because it is one of the plugins source folders and generally that means the code needs to be compiled as part of your project.
                Though this is true in general it isn't true here, because those classes have been copied into your project.

                I gather what happens on the commandline is that the plugin classes are compiled first and then then later replaced in the output folder
                when the project's main classes are compiled. So its not a problem for the command line tools that there is more than one of these around.

                As workaround, you can select each of the duplicated files in the original location, right click to get the context menu and then under "build-path" select "exclude".
                This will get rid of the errors, but, unfortunately they will come back the next time refresh dependencies gets called.

                At the moment, I don't have a good idea as to how you could make this classpath customization more permanent. I'll think about it some more :-)


                • #9
                  Thanks for doing all this research. I will try to make the temporary fix of excluding the files.


                  • #10
                    No problem. I've raised a Jira issue about this problem:

                    I don't really know a good way that we can fix this issue... but if all else fails I could add some 'special case' code to our refresh dependency logic specific to this plugin and exclude the plugin's domain folder from the build path. It's not pretty but it would work.


                    • #11
                      Do you have a suggestion on how to exclude the duplicate source files from compilation? The .link_to_grails_plugins path seems to be hidden from the PackageExplorer, and even though I can browse to the duplicate source file using the ctrl-shift-t command you suggested, I don't know how to exclude it at that point.

                      Thanks again!


                      • #12
                        You can find it under the 'plugins' node in the project explorer.

                        You can also disable the filters that hide stuff from you. In the views menu (accesible top-right corner of the view there's a "Customize View" thingy, in there you can enable/disable filters.
                        Disabling the "Grails Project Filter" will show you all the gory details we try to hide from you :-)

                        But... I think you should be able to also just see the folders below the "plugins" node so there's no need to disable the view filters.


                        • #13
                          FYI: I've committed a fix. You should be able to pick it tomorrow or so, by upgrading from the nightly update site:


                          After this fix, if you do refresh dependencies it should automatically exclude the four .groovy files in the spring-security-acl plugin's domain folder. Let me know if it works for you :-)


                          • #14
                            You can display the package roots (temporarily, if you like) from the project explorer. There is a little triangle at the upper-right corner of the view. Click it and select "customize view...". Then browse for "Grails project filter" and deselect. You can re-select it to hide the package roots again.