Kartik Shah wrote:What are the benefits provided by Griffon over just using regular Groovy SwingBuilder?
Griffon provides the following benefits over regular SwingBuilder:
A common application structure. You'll know your way around a Griffon application no matter who worked on it and when. All applications follow the same basic structure.
Managed application lifecycle, inspired by JSR 296 (Swing Application Framework)
Automated tasks, like create-app, test-app, compile, package, install-plugin. These tasks can certainly reduce the amount of work and time you have to spend developing and maintaining an application. They is a mechanism in place that make these tasks extensible; you can create your own as well.
A plugin ecosystem
Perhaps most importantly, the CompositeBuilder. It let's you mix and match builder nodes (like SwingBuilder, SwingXBuilder, GfxBuilder) seamlessly in the same script
Kartik Shah wrote:What is the roadmap for Griffon and can you comment on pace of its development?
The current roadmap contemplates
better integration with other build tools, like maven and gradle
complete overhaul of testing facilities provided out of the box
Kartik Shah wrote:When do you think we will have GORM type functionality ported to to Griffon?
There is some of it already, though it is not exactly GORM. Allow me to explain.
Griffon does not include Spring in its core as Grails does, however it provides a Spring plugin. Paired with the i18n and artifacts plugins it can provide the basis for what you can do with Grails. Persistence plugins like GSQL, Db4o, CouchDB, Neo4j and MongoDB can be used without domain classes today. They will be paired by another set of plugins that provide proper domain class support, and perhaps, even scaffolding. This will happen during the following months.