Hi Andy, thanks for your reply. Kris's comment sounded more like a "almost no more work planned here" rather than a "this is a low priority issue" and this is why I said it's sad, especially because in the past years Kris did a fantastic job on the Gradle integration for Eclipse and was very committed on it. Put in other words, he spoiled us
Anyway, I also think that if the Java ecosystem is fantastic when we talk about standards and platforms, the tooling aspects are always considered as low priority... This is in contrast with other much less spread technologies that are providing users with excellent tools from the beginning (think of Delphi, for instance).
Regarding Greclipse, I'll write you an e-mail, thank you. As an extreme summary, since Groovy is almost all about productivity, having a tool which is far behind the JDT tools in functionality does certainly not help. Also, it sometimes suffers of problems that are so severe that prevents you from using Groovy at all in an enterprise-grade project, at least if Eclipse is your IDE of choice.
Regarding the barrier to community adoption, I think there's also a great responsibility of companies that don't like to invest employees time to be spent on open source projects like these... So if the barrier is high it's difficult that one will be interested in spending his own spare time on them, especially because one needs time for real life, too. The extent of the Eclipse infrastructure also does not help: in my case, even if I'm an experienced Java SE/EE professional, I would need to learn SWT, the Eclipse Platform, OSGi, Eclipse plugin development, maybe EMF and so on to start to understand how things work...