No, it's not the next game in the Lego video game series. It's what I've recently checked into the development tree of Griffon: Plug-in support. This will solve a lot of bloat problems with the framework with regards to adding the latest (and some of the not so latest) bells and whistles for your Griffon applications. Don't need JIDE components? Then don't install the jide-builder plugin, even though you really want to. Need an installer for your application? griffon install-plugin installer will get you started. The number of plugins is small now, but that is only because those are the plugins we have been testing the plugin framework with.
So how do the plugins work? Well, mostly like Grails plugins. This is because the plugin framework is deeply inspired by the Grails 1.1 plugin framework (and by deeply inspired I mean many kilobytes of data have passed through my editor's cut and past buffer). Since Grails 1.1 is still very much in development the two codebases aren't totally derivitive, but once 1.1 ships I'll make sure Griffon reflects it's older brother code wise.
Being built off of Grails 1.1 the Griffon plugins may look a bit different. First, they no longer live in the project directory, but in the working cache in your home directory. There are references to the plugins in your application.properties file but that is the extent of data that must fit in your project. Second, because the location of a plugin has changed it wasn't that much of a stretch to allow plugins to be install globally (by adding the -global switch to your griffon install-plugin call), accessible to all projects. This is useful for plugins that are entirely build-time in their purpose, like the fest plugin which adds richer testing support.
Until we release a beta in a week or two you can play with the latest bits from the codehaus bamboo server.