Hello, I think I'm ready to take a superficial stand on this topic. Essentially, I can say that Xtend / Xtext will not be added as a dependency for jOOQ 3.0's code generator. I feel that these technologies are not
1. stable enough (Aaron himself pointed out various flaws repeatedly, e.g.: http://blog.pdark.de/2012/10/02/xtend-for-java-developers/) 2. independent enough (They create additional required compile-time and runtime-dependencies) 3. java enough (The tools impose a new non-Java but Javaesque syntax. jOOQ is about Java) 4. interoperable enough (Xtend / Xtext code cannot be mixed with Java code) While they seem to be nice tools to be used in highly specialised client environments, they cannot be imposed on a broader audience. However, the need for improved customisability of the code generator have been well received. What Aaron has shown to me proves that it is relatively simple to create a highly extensible, generic code generation API that allows for arbitrary artefact generation overrides. It should be possible to override default code generation with any other Java-based means, including Xtend / Xtext. I have also thought about moving away from string-based source code generation. For instance to the way XJC does with an object-oriented Java syntax model. I don't think jOOQ should go down that path either, as code generation isn't necessarily about Java (think of generating Scala, XML or any other code/document type). Cheers Lukas
