A Groovy world: why framework configuration APIs matter

Somebody is writing the next big framework as you're reading. It could be a new OR mapper, a new web framework, a build system or a dependency injection container.

Regardless of what this framework is designed for one thing will determine the level of integration it will get with Groovy and/or Grails: its configuration API.

Here's a list of frameworks that made it into the Groovy and/or Grails and rocked our world, thanks to their configuration APIs. People wrote builders for them or otherwise have integrated them in ways that could not have been foreseen nor were intended by their creators.

They are:

• The Spring Framework: BeanBuilder, used in the Grails plugin API.
• Hibernate: Grails dropped the XML and annotations and has hooked directly into Hibernate's configuration API. The JPA specs don't have one, guess why Grails is still based on Hibernate.
• SiteMesh: Grails dropped the XML configuration, hooked into the great API.
• iText: James Williams is writing a PDFBuilder
• Ant: although the API is hectic James Straghan succeeded in building AntBuilder on top of it and indirectly assisted in the birth of Gant.
• Ivy: great API, integrations with Groovy are being worked on.

Some notable frameworks that only have a limited integration with Grails simply because their creators did not provide a convenient, reusable configuration API:

• OpenLazslo: Grails plugin is available but the dream of a builder for creating views will never happen.
• ZK: impressive web framework, Grails plugin exists yet chances of a builder syntax for views is unlikely due to no configuration API.

Just imagine the power of being able to construct a view in Grails with just a few lines of Groovy code.

If you're working on this next generation frameworks, think of us Groovy developers and please abstract your configuration so that we can reuse your work.

Thanks and happy coding!