I will answer to Olaf's point outside of the original chain or replies, as I feel it is important enough.
Bigtop essentially has three stages in its life-cycle
- developing the code, content, packages, and other things consumed by the downstream users
- building and deploying the artifacts, which includes Maven artifacts for tests, and packages of the components and Bigtop's own utils
- runtime environment needed for smooth functioning of the Bigtop runtime and tests
Interestingly, all three need the presence of at least some parts of Groovy ecosystem. Respectively:
- requires an SDK to be available on the developer's machine so that IDE or CLI compilers can process the code written in Groovy and produce the bytecode. Not to mention highly convenient tools like GroovyConsole
- requires groovy compiler plugin, which will be automatically pulled in by the maven/gradle
- needs GRE (Groovy Runtime Environment) so that Groovy tests and iTest software can be executed
- we can build and install #3 and, perhaps, it will cover #1 but will create a non-trivial bootstrapping problem
- or we can say "real programmers do not use IDEs, so just use maven/gradle build" and then remove #1
- or do something completely different, that I can not imagine right now
But maybe I am not the only one who's using Groovy for the development in the Bigtop and I think it is important enough that such group of people has a reasonably unified development environment. It isn't about not eating our dog food. It is about having Groovy SDK conveniently installed when one configures his workstation. You don't have that issue with JDK, do you?