Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Build System

The major options for modular build systems are:

  • gradle
  • mvn (+gmaven)


  • compiler
  • runtime
  • groovysh (
  • groovyconsole (groovy.ui + friends)
  • groovydoc
  • swing
  • jmx
  • grape
  • mock
  • sql
  • ant (org.codehaus.groovy.ant)
  • javax.script
  • bsf
  • servlet
  • inspect
  • test/junit

Basically, anything not required for the the basic groovy language to execute, should be in a module. So groovy.GroovyShell (legacy), groovy.Grab*, groovy.util.GroovyTestCase are not required for the runtime to function. While useful, they should be in optional modules organized by function.



The groovy.lang (as well as groovy.util packages, should be limited to only core runtime bits. For example Anything grapes related should not be located here, if that is an optional module (which I suggest it is).

test support

All test support classes should be in a separate module. While tests are important, at runtime, they are irrelevant, and the runtime should not need to include them or depend on their requirements.

AST transforms

These are essentially optional components and should be packaged in groovyx.lang and included in optional modules, ie. if its not required to have the core runtime work, it should be in a module.

XML support

There are current xml support classes in groovy.util and groovy.xml. They should all be in groovy.xml.

SVN Structure

The current SVN structure does not really follow standards. For example, groovy-core, a separately release component (at the moment, hope to change), is located at:

This should really be something like:

The modules listed above would be listed under:<module>

And they would be release together. Completely optional projects, like the native support, ide support, etc. should be located at:<project>/trunk


Another way to look at things, is that if you have a listed dependency in the pom.xml which is optional... the classes which need that dep are good candidates to move to a separate module.

  • No labels