Grails is an MVC action-based web framework inspired by the principle of "convention over configuration." It leverages many of the features of Groovy, Spring MVC and Hibernate. A wide range of plugins are available for rich client/Ajax development, Web services and performance management. In this presentation, recorded at the recent Grails Exchange event in London (organized by Skills Matter), Grails co-founder Graeme Rocher explains how to go about getting the best out of the Grails plug-in architecture by demonstrating how to create re-usable plugins that can be distributed, installed and managed. Dowload the slides for this presentation here. Watch other Tech Briefs

i'm amazed that this hasn't been done before. i use grails quite a lot and plugins work really well, but there are times that i wish i could bundle non-grails plugins without having to set them up as grails plugin projects first. there are so many candidates for plugins in most projects, like login/logout screens, forgotten passward etc., it would be great to see this idea fleshed out a little more with the grails dependency.

Due all respect, i hear crickets when subject is Grails in TheServerSide. Grails may be a decent project, but to me that project is losing big time because it includes the word "rails" word in it. it sounds like a cheap wanna be. And i still do not have interest in neither.

I was a Grails Skeptic like you , seeing it as a poor Man's version of Ruby on Rails (and so preferring to spend my time on JRuby). However, after seeing some of Groovy / Grails presentations at the IJTC I've changed my mind, or at least been persuaded to give it a 2nd look. The main reason for my change of mind is the syntax. Groovy / Grails syntax is a lot more 'natural' for Java programmers. Now I know Ruby syntax is easy to pick up, but Groovy is even easier (and sometimes there are good reasons to be lazy!)

Grails looks interesting. I spent a lot of time in the last year working with Seam + Facelets (which requires JSF) + [MyFaces, Tomahawk, Richfaces + Ajax4JSF (now combined), etc...]. The programming model of Seam, that of using annotations to express dependencies is its most compelling feature. The business of tracing each framework component and working out integration issues is a nightmare that gets worse with each release of Seam (1.1 -> 1.2 -> 2.0) and/or one of the companion frameworks listed above and/or JBoss application server. And you can be sure that this will only get worse if/when Seam tries to become web beans forcing recoding of Seam applications that want to move to the web beans model because let's face it, the annotations are completely different in web beans. Grails appears to be full stack in the sense that it just provides 'all the parts' (i.e. ORM, scaffolding, tags, code generation, etc.). If each of Grails constituent parts works seamlessly (no pun intended) with each other, then this would be a nice improvement over the current Seam experience. I like the fact that I can select which javascript library to use in Grails. I agree that there are good reasons to be lazy and in that spirit I claim that working out companion framework integration is of no value to the developer (i.e. framework user/consumer). Part of the pitch of a good framework is high leverage / better productivity / no need to change code as the framework version numbers increase. I'm tired of unexpected surprises from my frameworks. It's well past time to look at full-stack open-source frameworks like Grails, Rails, etc. IntelliJ IDEA already has good plugins for working with Grails, Rails + ruby, GWT, etc. Let's face it our bosses / clients aren't interested in paying us to work out why framework A won't play nice with a feature in framework B.

Springframework. It doesn't pretend to be a full stack, just works in its domain.

Grails in fact uses Spring under the covers. Would be nice if there were more spring integration points exposed, especially with AOP and web flow -- though the first thing grails has to tackle is having documentation that isn't complete crap when it's even there at all.

Grails in fact uses Spring under the covers. Would be nice if there were more spring integration points exposed, especially with AOP and web flow.

There are already a couple of integration points. Also, there is a nice integration between Grails and web flow. The complete flow can be described in Groovy (using Builders), so no more XML. See: http://grails.codehaus.org/WebFlow

The first thing grails has to tackle is having documentation that isn't complete crap when it's even there at all.

There are some books about Groovy and Grails. "The Definitive Guide to Grails (aPress)" is still a very good description of Grails and it's concepts, but it is not consistent with the current release. The book is currently being updated to be consistent with Grails 1.0. The wiki based documentation is not bad and pretty complete. Also Graeme Rocher has published a first version of a reference manual that is available here: http://grails.org/doc/RC1/ Overall I think Groovy and Grails are great for Java, because they make the simple things simple (using DRY, convention of configuration..), but have a strong and stable foundation (Java like syntax, allow to mix Groovy and Java, Hibernate, Spring, Sitemesh, ..). Stephan Albers http://www.jcatalog.com/

I agree. Grails is a pretty cool framework that rivals RoR for rapid development. Being able to reuse much of my existing Java code and ability to deploy as a war file are clear advantages over RoR to me. Great stuff (uninspiring name aside).