Mohadib,
I'll really need more details on what you mean by 'checking out as Grails'. I take it you are talking about getting a project out of some version managament system, like SVN or CVS.
Would need to know details about what version management system and which Eclipse tools are used for this. For example with subversion there is subclipse and subversive to choose from, and people using one or the other are having different experiences.
Also, I'd need to know how the project was shared and exactly which steps the user/developer is taking to import them. One thing that can cause a lot of trouble is if developers decide not to put Eclipse configuration files under version control, having these files missing confuses Eclipse / STS since those files configure how your project works in STS.
The recent improvements I made are related to this. I try to detect missing / broken configurations when new projects are added to the workspace. Unfortunately, this tricky, because projects can get broken in many ways, so I'm sure I'm missing come cases that need better handling.
An example (maybe happening for your developer, but I'm just guessing). If the user is explicitly not versioning files like (.project, .classpath and .settings) and then later on using some broken import wizard that creates new Grails configs that are incorrect (some SVN tools are known to do that!) then it would make sense why 'import as Grails' doesn't work and 'import as Groovy' does. Because when you call 'Convert to Grails' the correct configs will be recreated. But if you start by restoring an incorrect configuration, then we don't get the opportunity to fix them (the configs are there, so it looks 'ok' but they are in fact corrupt).
Anyway, please tell me what version management system is being used, and I can probably provide help in how to share / import projects reliably.
Kris
Kris De Volder -- SpringSource