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 :-)
Kris De Volder -- SpringSource