Virtually all Groovy work involved Grails. There's no other reason to adopt Groovy. If you need standalone scripts in an IDE, it's easier to use, say, Eclipse Xtend (http://www.infoq.com/news/2012/06/xtend-release-10)
No, Groovy is used in many other places than Grails.
One can think of the Gradle build automation tool (http://gradle.org/), for instance, which uses Groovy as a DSL.
But actually, one of the very big use cases for Groovy outside of Grails is as an embedded DSL, for business-oriented languages, to further customize the business rules of an application, for configuring it, etc.
Groovy's used in many sectors: healthcare, insurance, banking, travel, scientific simulations, biomedical, etc.
> No, Groovy is used in many other places than Grails. One can think of the Gradle build automation tool (http://gradle.org/), for instance, which uses Groovy as a DSL.
Gradle's the only provable specific example you gave of Groovy being used as a DSL. But is Gradle used for much more than building Groovy, Grails, and Griffon?
Unfortunately, I cannot give some of the real-world DSLs that I know of or that I've worked on, as my customers request that we don't publicize that information.
Just to give you a couple examples which are more or less public, I can mention the Amadeus travel company (whose services are used by 80% of airlines and travel agencies in Europe) or the European Patent Office who did presentations at conferences about their usage of Groovy for DSLs.
The various sectors I mentioned earlier are sectors for which I know companies that are using Groovy for such DSL purposes, although I'm not in a position to publicly speak about them unfortunately :-(
As for Gradle, yes, of course, it's used beyond the Groovy ecosystem. For example, the Spring project (and other related Spring projects) is built with Gradle, as well as Hibernate. Some major projects have switched to Gradle from Maven.
Your statement is reductive. You can replace xtend by all the new jvm language. In fact these languages haven't proove anything. On the contrary of groovy.
On my own experience I use groovy not only for grails :
- virtually all java classes can be replaced by groovy classes. Groovy is far more concise. eg. I use groovy for spring/backed bean.
All your examples are controlled by the Groovy/Grails business in some way. Groovy bundles both gpars and Swingbuilder in its distro, and Spring is bundled in Grails.
The Not-Invented-Here mentality has always been prevalent in the VMWare-funded "Gr8te" ecosystem. If someone independently builds something using Groovy or Grails, such as Alex Tkachman, Roshan Dawrani, et al building Groovy++, VMWare make excuses to reject it, then build their own version, Groovy 2's static compilation, probably copying plenty of code out of Groovy++ along the way.
This mentality results from VMWare wanting to control as much of Grails's constituent technologies as possible. The reason behind Gradle becoming the build tool for Groovy/Grails, Spring, and Hibernate was for Gradleware to pitch their control of Hibernate's build, knowing they'll be targeted for a buyout by VMWare. Rocher's probably hard-balling the Gradleware execs right now, trying to screw them for as much as possible.
