I'm starting a list of the changes necessary for the plugin to be compatible with Grails 0.6. A question arises here: should there be an attempt to maintain compatibility with Grails 0.5.6? It wouldn't be difficult to at least temporarily (and hackishly) provide backwards compatibility with the changes I've identified thus far, but I don't think the plugin shouldn't bother maintaining such backwards compatibility at this point. I suggest that I commit these changes once an 0.6 release candidate is available, thus making the plugin 0.6-only (until the next Grails update). A more general question is how such backwards compatibility might be maintained in the future. The Grails version can be determined by loading the Grails core jar and invoking grails.util.GrailsUtil.getGrailsVersion(). Would it help if a Grails jar was shipped with the plugin in the same way as a Groovy jar? Or should the Grails jar be located at run-time by using the plugin config info? Grails 0.6-related changes: 1. The class org.codehaus.groovy.tools.GroovyStarter (used by grails launcher script) is now in $GRAILS_HOME/lib/groovy-all-1.1-beta-3-SNAPSHOT.jar $GRAILS_HOME/lib/groovy-starter.jar (which has been removed). GrailsRunConfiguration.getState() should be updated with the new path. Temporary compatibility with 0.5.6 could be provided by adding the Groovy snapshot distribution to the run configuration classpath rather than just replacing the groovy-starter.jar. 2. Grails 0.6 no longer creates a "src/test" folder. The existence test for this folder should be removed from GrailsModuleBuilder.MyModuleBuilderListener.moduleCreated(). Temporary compatibility with 0.5.6 (sort of) could be provided by moving this existence test to last in the list and not failing if the folder is not found, the assumption being that if all the other folders checked do exist then the project structure is probably OK (i.e., was created by 0.6)