Saturday, May 15, 2010

Extending Groovy-Eclipse for use with Domain-Specific Languages Part II

A while ago, I wrote an article about how to extend Groovy-Eclipse for domain specific languages. It was always my intention to write a follow-up that included an example project. Thanks to some prodding on the mailing list, here it is, 5 months later. I finally have an example Groovy-Eclipse extension project available.

The code mostly speaks for itself, so if you are interested in how to extend Groovy-Eclipse, first read part I of this article, and then download the example project.

Here is the example plugin project that extends Groovy-Eclipse. Import this plugin into your Eclipse development workspace.

And here is a simple runtime project that uses all of the extensions provided in the plugin project. Import this project into your Eclipse runtime workspace. If you want to create your own project that uses this example, be sure to add the following project nature to your .project file:
org.codehaus.groovy.eclipse.example.nature
Once again, the code speaks for itself, so there is nothing more that I need to say about it. Enjoy!

3 comments:

  1. Thank you Andrew for that !
    I'm sure that will help me!

    ReplyDelete
  2. This is interesting, in that Eclipse support for new DSLs is always welcome.

    However, this concept begs the question: why not create a DSL for extending Groovy-Eclipse, or, more generally, for writing PDE plugins?

    There's already a Groovy SWT wrapper (http://groovy.codehaus.org/GroovySWT). Groovy's XML handling is stellar (http://groovy.codehaus.org/Processing+XML). The Builder framework seems to crop up everywhere (http://groovy.codehaus.org/Builders).

    Couldn't these capabilities be combined to make a GEBuilder (Groovy-Eclipse Builder) or a PDEBuiler (GEBuilder should probably extend PDEBuilder...)?

    Just a thought.

    ReplyDelete
  3. One of our features targeted for the 2.1 release is a DSL targeting Groovy-Eclipse itself. The focus will be a declarative extension of the inferencing engine (and maybe some editor features). Performance is a concern and the more general purpose we make such a DSL, the more likely that a third party extension will break our specific Groovy and Java model caching mechanisms.

    As for a PDEBUilder DSL, I could imagine using some kind of XMLBuilder (perhaps a bit specialized though) to construct the plugin.xml and MANIFEST.MF files, but I haven't given much thought into that since I do like the PDE's form editor for plugins that visually combines the contents of the plugin.xml, manifest, and build.properties.

    ReplyDelete