The major options for modular build systems are:
- mvn (+gmaven)
From DevCon5: core?, numbers?, strings? bsf, jsr223, sql, xml, jmx, time, date, collections, cli, maps, file, streams, process, threads, templates, regex?, encoding, ant, newify?, googleCollections, jsr203/nio, jodatime, actors, combinators, BigTable?, Scala compiler hooks/Scalify
- groovysh (org.codehaus.groovy.tools.shell)
- groovyconsole (groovy.ui + friends)
- ant (org.codehaus.groovy.ant)
Basically, anything not required for the the basic groovy language to execute, should be in a module. So
groovy.util.GroovyTestCase are not required for the runtime to function. While useful, they should be in optional modules organized by function.
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).
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.
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.
There are current xml support classes in groovy.util and groovy.xml. They should all be in groovy.xml.
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:
And they would be release together. Completely optional projects, like the native support, ide support, etc. should be located at: