...
- Modularity with Grapes
- Status
- Early discussion phase but leveraging existing concepts like grapes and GROOVY-2116 (James Strachan's service registration proposal but enhanced)
- Create a branch for playing with the concept and merge back onto 1_7_X/trunk at some point if successful
- Nice to be able to enable some small bits before 1.7 beta but will depend on speed of creation followed by speed of feedback
- Motivation
- How to stop groovy-all jar from getting "too fat"
- How to evolve GDK without breaking (or at least controlled breakage of) legacy scripts
- How to better position Groovy for use in a wide range of scenarios (e.g. mobile)
- How to allow Groovy ecosystem to blossom by allowing many grapes to be created but without requiring all of them to be bundled
- Proposed changes visible to users
- leverage grape system even for Groovy's GDK (may involve "bundled grapes")
- enhance GroovyStarter/LoaderConfiguration to support --grab on commandline and grab in conf file (see also GROOVY-3215 conf file in Groovy)
- (slightly orthogonal but related change) enhance AST transform support to allow scripts to grab without need for a class or method definition, e.g. "@grab(...) Script" (or replace Script with "this" or something else)
- non-all jar will be much slimmer but conf file will download other jars or at least use other jars in distribution zip
- service registration (GROOVY-2116) but enhanced. Each grape can have a META-INF/services/groovy directory with one or more of the following files
- groovyMethods - list of class files containing normal category methods to be registered at global level
- groovyStaticMethods - list of class files containing static category methods to be registered at global level
- groovyExpandoMethods - list of class files containing expando defns
- groovyAstTransforms - ?? but only transforms that come after grape phase?
- groovyBuilderMetadata - ?? of help to IDEs, e.g. AntBuilder/SwingBuilder
- auto import registration
- runner registration (e.g. easyb runner like testng runner)
- existing grapes can be changed to better handle "service registration"
- gdk (or pieces) will start to have version numbers (how to relate version numbers with corresponding runtime versions?)
- Proposed changes invisible to users
- all-jar will come bundled with (almost?) all current functionality (opportunity to remove deprecated functionality?)
- minor changes to current source structure (but do we move to almost like separate 'modules' and move tests)
- minor changes to build files
- Points to consider
- which parts of GDK to tackle All? All but core? Just some less used parts to start with? Tools?
- granularity of grapes
- "@grab xml" vs "@grab xml.slurper and @grab xml.parser"
- "@grab jmx" vs "@grab jmx.builder"
- names to use? ivy/maven/OSGi
- versioning scheme to use
- potential grapes:
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 - format of META-INF/services file: list of classes or groovy file
- graceful degradation: jars, poms, OSGi manifest, META-INF/services
- think through implications for various embedded usages of Groovy
- Status