Skip to end of metadata
Go to start of metadata

As of Groovy-Eclipse 2.5.2, there is now command line support for testing DSLD descriptors. Because DSLD support us intertwined with Eclipse API, it is not possible to simply run unit tests against them. Rather, it is necessary to load up the Eclipse workbench and process the DSLD files from within the workbench in order to evaluate them.

Setting up

You can only evaluate DSLDs against an existing Eclipse project. So, you need to create an eclipse project inside an existing workspace.

  1. Start Eclipse
  2. Create a groovy project
  3. Create some Groovy classes
  4. You can add your DSLDs directly to this project, or you can add them later when you perform the type checking.
  5. Add some type annotations to assert the static types of certain expressions. Eg-

Shut down Eclipse and you are ready to run static type checking.

Running static type checking

The command looks like this:

Here is a description of the arguments:

--help OR -h

Prints a help message and exits.


list of extra dsld files to be included in this check. Use '|' as a file separator.


Don't report unknown types. Only look for type assertions


Project-relative exclusion filters.


Project-relative inclusion filters.


Name of a project to type check. Must be already in the workspace.

The exclusion and inclusion filters use the syntax from ant filesets. Individual filters can be concatenated using '|'.

For example:

includes all files, but excludes all *Test.groovy files in test/java and test/groovy.

The results

Let's assume that there is a Groovy project in an Eclipse workspace with a single file:


And this DSLD file exists outside of the workspace:


Then executing this command:

Will produce the following output:

If you want to suppress all of the unknown type warnings, then include the --assertions_only parameter on the command line.

You may also see some error messages sent to syserr, like this:

These messages can be safely ignored. These messages occur since Eclipse is being shut down early enough before all initialization jobs are complete. We'll be fixing this in future versions.

More to come

This is just a first pass at static checking. We are looking for feedback as to the best way to display failed assertions, or if there is anything else that can be improved. If there is significant interest, we can do the work to make it easy to create JUnit (or Spock!) tests for DSLDs, but we need to hear the feedback first.

  • No labels