STS complains about missing classes

[Gene Golovchinsky]

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.Secured
grails.plugins.springsecurity.acl.AbstractAclObjec tIdentity
etc.

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?

Thanks,

Gene

[Gene Golovchinsky]

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.

[Andrew Eisenberg]

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.

[Gene Golovchinsky]

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.

[Gene Golovchinsky]

I did refresh dependencies, but that did not help.

[Kris De Volder]

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: https://issuetracker.springsource.com/browse/STS-1792).
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.

[Gene Golovchinsky]

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?

[Kris De Volder]

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:
http://jira.grails.org/browse/GPSPRINGSECURITYACL-3

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 :-)

[Gene Golovchinsky]

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

[Kris De Volder]

No problem. I've raised a Jira issue about this problem: https://issuetracker.springsource.com/browse/STS-1799

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.