Well, at the moment, we unfortunately don't have a regular maintainer for Groovy-Eclipse. But I plan to update Groovy-Eclipse myself with support for GMavenPlus (so you don't have to do the custom lifecycle mapping thing) in the coming weeks (should be an easy code change, I just need the time to test it -- I talked about doing this with Andrew Eisenberg quite a while back, but it fell off my radar, sorry). In the mean time, I'm pretty sure what you did should be fine.
Thanks for mentioning 2.4.4 issue (as an IntelliJ guy, I tend not to notice). If I get some free time, I'll also take a look at updating for Groovy 2.4.4/2.4.5.
I'm not sure offhand how much work that'll be (if it doesn't suck too much of my life away, I'll keep it updated from now on until we find someone with more Eclipse compiler expertise to take over proper maintenance of the project).
It's true Groovy-Eclipse uses forked classes. In some ways though, they have more functionality than the official classes (in fact we'd talked about merging some of this with upstream Groovy after we finish the ANTLR 4 stuff -- currently considering for whenever we do Groovy 3). But I was never comfortable using them because there were occasional differences I've seen in what would compile in Groovy-Eclipse vs what would compile with groovyc/GMavenPlus/Gradle. You can see the forked classes for Groovy 2.4 here
. But I think the reason most folks recommend something like GMavenPlus over Groovy-Eclipse isn't because there are minor compilation differences, but because there are things
you can't do in Groovy-eclipse (e.g. Groovydoc, invokedynamic, configuration scripts).
Short answer: I don't like labeling my advice the "official" word (since as the GMavenPlus author, my opinion may appear biased), but I think the community consensus concurs with me. I'd suggest using GMavenPlus with the lifecycle mapping as you have done, then remove the mapping once I patch Groovy-Eclipse.