[dev] Initial checkin of new plugin infrastructure

[Steven Devijver]

Guys,

I've committed the initial version of the plugin infrastructure for
Grails. This is an exciting new feature for 0.2 and beyond that takes
the Groovy platform to a new level.

For those of your familiar with the SpringConfig class, the plugin
infrastructure replaces the creation of bean definition in the Spring
ApplicationContext and offers a much more flexible mechanism.

What does this new plugin infrastructure mean for Grails? In short,
*anyone* will be able to drop a jar in the Grails class path - this
the is lib directory of a Grails project - that contains a
META-INF/GrailsPlugins.xml file. These are regular Spring XML files
that contain plugin classes. This mechanism allows for extremely easy
addition and removal of features to Grails.

Want to add web services to Grails? Just download the Grails-WS jar
file and drop it in the lib folder. Want to add new dynamic
persistence methods? Sure, just create your methods, create and
configure a plugin class that registers them and drop in the jar. Have
your own neat tag library? Just drop in the jar.

Now, what are the consequences for Grails as we know it today? There
are quite a few, here's the list:

1. Grails artifact types should become dynamic - compared to static as
they are now - so that new artifacts can be added seamlessly - REST
controllers, webservices, ....
2. The core Grails features - class parsing/artifacts/method mediation
+ the plugin architecture - should be moved to a Grails Core module.
3. The regular Grails functionalities - persistence, services, domain
classes, controller, webflow, ... - should be moved to another module
- for examples Grails Web.
4. GSP files should be loadable from the class path. Currently there's
a GSPServlet. This should be refactored to work through the Spring MVC
view abstraction so that the location of GSP files is not longer tied
to the WAR level. This will enable anyone to drop in a jar that
contains Groovy controller files and GSP view files.

So what's the status of all this? First of all, the plugin
infrastructure is not finished yet. I've already ported quite a lot
that's currently in SpringConfig to plugins but I ran into some issues
that need to be discussed.

Some of the changes I propose have an important impact on the existing
code so they need to be considered carefully. So I guess it's going to
take some weeks/months until everything is converted to the plugin
infrastructure. There's a lot of work to be done and I encourage all
developers to have a look at the code and tests that I've committed so
far to become familiar with the new infrastructure.

So how do these plugins work? Basically the plugins are loaded in two steps.

The first step is to load all META-INF/GrailsPlugins.xml files into a
Spring application context. This will load all plugin beans.

The second step is to invoke all plugins. Each plugin has full access
to a Spring application context which will become the application
context of the Grails application. To this application context
BeanDefinitions can be added, as well as BeanPostProcessors and a
whole host of other Spring stuff. This is extremely good news since
the full power of the Spring container becomes available to Grails.
Spring 2.0 adds so nice new feature that could be very useful for
Grails.

So, that's it for now. I hope everyone's as excited as I am about the
plugins. If you think about it, the core plugin framework combined
with the core Grails classes form the backbone of what I consider
Groovy on Steriods. Through plugins you can build any system on top of
Groovy - be it Grails or a Groovy-backed ESB or a workflow engine or
whatever you want.

You'll be able to register custom methods, custom builders, add
artifacts and do all kinds of awesome and cool things. Grails is just
one instantiation of Groovy on Steriods, it can become anything you
want. And the good news is that the plugin and the core code make all
the nice Groovy features available and extensible through a very
consistent API.

Personally I'm convinced that this plugin infrastructure is much more
powerful than anything they've seen in Ruby land. Come on guys, let us
unite and build some kickass features that will make Grails shine.

Until later

Steven

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[graemer]

Congratulations Steven, I took a look (by no means comprehensive) at
the code and it looks very well thought out.

I have some questions/comments/requests regarding the codebase:

1) To encourage adoption of the plug-in mechanism it needs to be well
documented. Could you write up a page on the wiki demonstrating
exactly how to go about writing a plug-in?
2) If you look at other popular frameworks that support plug-ins they
tend to define "extension points" are these part of this framework? If
so what are they? If not can we define them? Or is it just a matter of
documentation?
3) It wasn't clear from the code how Grails loads the plugins. Will it
do a classpath search for all jars with the GrailsPlugin.xml file
defined?
4) Clearly with this I think its time to start thinking about creating
a modules directory within Grails and adding the ability to install a
module to the grails script. As there is a lot of functionality that I
can think of that should be in a separate module and not part of
Grails core. What do you think? How do you envisage this working?
5) Finally, you have a clearer idea of what needs to be done for us to
fully take advantage of plug-ins. Given this could you create the JIRA
tasks need for us to complete the migration?

Again, great work and I think this should make things infiinitely
clearer in terms of how to go about developing, extending and
improving Grails going forward

Cheers
Graeme



On 5/25/06, Steven Devijver <[hidden email]> wrote:

> Guys,
>
> I've committed the initial version of the plugin infrastructure for
> Grails. This is an exciting new feature for 0.2 and beyond that takes
> the Groovy platform to a new level.
>
> For those of your familiar with the SpringConfig class, the plugin
> infrastructure replaces the creation of bean definition in the Spring
> ApplicationContext and offers a much more flexible mechanism.
>
> What does this new plugin infrastructure mean for Grails? In short,
> *anyone* will be able to drop a jar in the Grails class path - this
> the is lib directory of a Grails project - that contains a
> META-INF/GrailsPlugins.xml file. These are regular Spring XML files
> that contain plugin classes. This mechanism allows for extremely easy
> addition and removal of features to Grails.
>
> Want to add web services to Grails? Just download the Grails-WS jar
> file and drop it in the lib folder. Want to add new dynamic
> persistence methods? Sure, just create your methods, create and
> configure a plugin class that registers them and drop in the jar. Have
> your own neat tag library? Just drop in the jar.
>
> Now, what are the consequences for Grails as we know it today? There
> are quite a few, here's the list:
>
> 1. Grails artifact types should become dynamic - compared to static as
> they are now - so that new artifacts can be added seamlessly - REST
> controllers, webservices, ....
> 2. The core Grails features - class parsing/artifacts/method mediation
> + the plugin architecture - should be moved to a Grails Core module.
> 3. The regular Grails functionalities - persistence, services, domain
> classes, controller, webflow, ... - should be moved to another module
> - for examples Grails Web.
> 4. GSP files should be loadable from the class path. Currently there's
> a GSPServlet. This should be refactored to work through the Spring MVC
> view abstraction so that the location of GSP files is not longer tied
> to the WAR level. This will enable anyone to drop in a jar that
> contains Groovy controller files and GSP view files.
>
> So what's the status of all this? First of all, the plugin
> infrastructure is not finished yet. I've already ported quite a lot
> that's currently in SpringConfig to plugins but I ran into some issues
> that need to be discussed.
>
> Some of the changes I propose have an important impact on the existing
> code so they need to be considered carefully. So I guess it's going to
> take some weeks/months until everything is converted to the plugin
> infrastructure. There's a lot of work to be done and I encourage all
> developers to have a look at the code and tests that I've committed so
> far to become familiar with the new infrastructure.
>
> So how do these plugins work? Basically the plugins are loaded in two steps.
>
> The first step is to load all META-INF/GrailsPlugins.xml files into a
> Spring application context. This will load all plugin beans.
>
> The second step is to invoke all plugins. Each plugin has full access
> to a Spring application context which will become the application
> context of the Grails application. To this application context
> BeanDefinitions can be added, as well as BeanPostProcessors and a
> whole host of other Spring stuff. This is extremely good news since
> the full power of the Spring container becomes available to Grails.
> Spring 2.0 adds so nice new feature that could be very useful for
> Grails.
>
> So, that's it for now. I hope everyone's as excited as I am about the
> plugins. If you think about it, the core plugin framework combined
> with the core Grails classes form the backbone of what I consider
> Groovy on Steriods. Through plugins you can build any system on top of
> Groovy - be it Grails or a Groovy-backed ESB or a workflow engine or
> whatever you want.
>
> You'll be able to register custom methods, custom builders, add
> artifacts and do all kinds of awesome and cool things. Grails is just
> one instantiation of Groovy on Steriods, it can become anything you
> want. And the good news is that the plugin and the core code make all
> the nice Groovy features available and extensible through a very
> consistent API.
>
> Personally I'm convinced that this plugin infrastructure is much more
> powerful than anything they've seen in Ruby land. Come on guys, let us
> unite and build some kickass features that will make Grails shine.
>
> Until later
>
> Steven
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Steven Devijver]

On 5/26/06, Graeme Rocher <[hidden email]> wrote:
> Congratulations Steven, I took a look (by no means comprehensive) at
> the code and it looks very well thought out.
>
> I have some questions/comments/requests regarding the codebase:
>
> 1) To encourage adoption of the plug-in mechanism it needs to be well
> documented. Could you write up a page on the wiki demonstrating
> exactly how to go about writing a plug-in?

I totally agree on this, the plugin mechanism must be documented. The
plugin infrastructure that is currently committed to CVS is
rudimentary but it does implement the basic ideas that are worth
explaining.

> 2) If you look at other popular frameworks that support plug-ins they
> tend to define "extension points" are these part of this framework? If
> so what are they? If not can we define them? Or is it just a matter of
> documentation?

"Extension points" indicates "something is extended". In the case of
Grails this is not really the case since "plugins" build on top of the
Groovy language, the Spring Framework, Hibernate and other frameworks
and API's. We can discuss this because maybe "plugin" is not the
correct term either. For now however I would like to stick to "plugin"
as for me it means "additing components or functionality" which is
exactly what this infrastructure does.

> 3) It wasn't clear from the code how Grails loads the plugins. Will it
> do a classpath search for all jars with the GrailsPlugin.xml file
> defined?

I'm still working on this. I've talked to some people in recent weeks
that have shown interest in using the Grails plugin mechanism
elsewhere. For now I've included a GrailsPluginLoader class that loads
the plugins but this class is almost certainly not going to stay.

> 4) Clearly with this I think its time to start thinking about creating
> a modules directory within Grails and adding the ability to install a
> module to the grails script. As there is a lot of functionality that I
> can think of that should be in a separate module and not part of
> Grails core. What do you think? How do you envisage this working?

Well, each module should be a separate JAR file since features are
added by dropping in JAR files. So any project infrastructure that
facilitates the release of separate modules sounds very suitable.

> 5) Finally, you have a clearer idea of what needs to be done for us to
> fully take advantage of plug-ins. Given this could you create the JIRA
> tasks need for us to complete the migration?

Definitely, one or more JIRA issues make sense.

Steven

>
> Again, great work and I think this should make things infiinitely
> clearer in terms of how to go about developing, extending and
> improving Grails going forward
>
> Cheers
> Graeme
>
>
>
> On 5/25/06, Steven Devijver <[hidden email]> wrote:
> > Guys,
> >
> > I've committed the initial version of the plugin infrastructure for
> > Grails. This is an exciting new feature for 0.2 and beyond that takes
> > the Groovy platform to a new level.
> >
> > For those of your familiar with the SpringConfig class, the plugin
> > infrastructure replaces the creation of bean definition in the Spring
> > ApplicationContext and offers a much more flexible mechanism.
> >
> > What does this new plugin infrastructure mean for Grails? In short,
> > *anyone* will be able to drop a jar in the Grails class path - this
> > the is lib directory of a Grails project - that contains a
> > META-INF/GrailsPlugins.xml file. These are regular Spring XML files
> > that contain plugin classes. This mechanism allows for extremely easy
> > addition and removal of features to Grails.
> >
> > Want to add web services to Grails? Just download the Grails-WS jar
> > file and drop it in the lib folder. Want to add new dynamic
> > persistence methods? Sure, just create your methods, create and
> > configure a plugin class that registers them and drop in the jar. Have
> > your own neat tag library? Just drop in the jar.
> >
> > Now, what are the consequences for Grails as we know it today? There
> > are quite a few, here's the list:
> >
> > 1. Grails artifact types should become dynamic - compared to static as
> > they are now - so that new artifacts can be added seamlessly - REST
> > controllers, webservices, ....
> > 2. The core Grails features - class parsing/artifacts/method mediation
> > + the plugin architecture - should be moved to a Grails Core module.
> > 3. The regular Grails functionalities - persistence, services, domain
> > classes, controller, webflow, ... - should be moved to another module
> > - for examples Grails Web.
> > 4. GSP files should be loadable from the class path. Currently there's
> > a GSPServlet. This should be refactored to work through the Spring MVC
> > view abstraction so that the location of GSP files is not longer tied
> > to the WAR level. This will enable anyone to drop in a jar that
> > contains Groovy controller files and GSP view files.
> >
> > So what's the status of all this? First of all, the plugin
> > infrastructure is not finished yet. I've already ported quite a lot
> > that's currently in SpringConfig to plugins but I ran into some issues
> > that need to be discussed.
> >
> > Some of the changes I propose have an important impact on the existing
> > code so they need to be considered carefully. So I guess it's going to
> > take some weeks/months until everything is converted to the plugin
> > infrastructure. There's a lot of work to be done and I encourage all
> > developers to have a look at the code and tests that I've committed so
> > far to become familiar with the new infrastructure.
> >
> > So how do these plugins work? Basically the plugins are loaded in two steps.
> >
> > The first step is to load all META-INF/GrailsPlugins.xml files into a
> > Spring application context. This will load all plugin beans.
> >
> > The second step is to invoke all plugins. Each plugin has full access
> > to a Spring application context which will become the application
> > context of the Grails application. To this application context
> > BeanDefinitions can be added, as well as BeanPostProcessors and a
> > whole host of other Spring stuff. This is extremely good news since
> > the full power of the Spring container becomes available to Grails.
> > Spring 2.0 adds so nice new feature that could be very useful for
> > Grails.
> >
> > So, that's it for now. I hope everyone's as excited as I am about the
> > plugins. If you think about it, the core plugin framework combined
> > with the core Grails classes form the backbone of what I consider
> > Groovy on Steriods. Through plugins you can build any system on top of
> > Groovy - be it Grails or a Groovy-backed ESB or a workflow engine or
> > whatever you want.
> >
> > You'll be able to register custom methods, custom builders, add
> > artifacts and do all kinds of awesome and cool things. Grails is just
> > one instantiation of Groovy on Steriods, it can become anything you
> > want. And the good news is that the plugin and the core code make all
> > the nice Groovy features available and extensible through a very
> > consistent API.
> >
> > Personally I'm convinced that this plugin infrastructure is much more
> > powerful than anything they've seen in Ruby land. Come on guys, let us
> > unite and build some kickass features that will make Grails shine.
> >
> > Until later
> >
> > Steven
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email