Useful build tasks
- `installGroovy` or `iG` will build a local install of Groovy which can be used for testing (consider `-PskipIndy` if you don't need indy and want a faster build)
- `install` will publish to local Maven repo
- `testAll` to run the test suite
- `groovydocAll` to produce Groovydoc for all modules
- `:test --tests=some.package.SomeTest` to run an individual test
Build cache
The Groovy build makes use of Gradle's build cache. This speeds up the build in many scenarios but sometimes gets in the way (we no doubt have tasks in our build that aren't properly configured wrt stale output). In such cases, use `--no-build-cache` when running tasks.
Binary compatibility
We regard binary compatibility as very important. It's not simply an issue related to how our build works but it impacts many Groovy users. When making changes API, it's not just a case of checking for all usages within the Groovy codebase that might be impacted but also whether changes will impact other projects and users of Groovy. In particular changes related to the Groovy runtime must be done with extreme care. These are the classes that compiled Groovy code might call into during execution.
In general, we try to evolve the Groovy codebase to minimise impact on Groovy-based frameworks. For example, we'd ideally like a Grails application built with Groovy 3 to work with a Grails plugin compiled under Groovy 2.5. This isn't always possible but we should then make life easier for frameworks by appropriate documentation when a breaking change is needed (see hints below).
In theory, classes under the `org.codehaus` and 'org.apache' packages are more internal than those in the `groovy` package. But users of Groovy will use any public/protected class, so make changes in all areas of the codebase with care. [NOTE: If we start using JDK9+ modules more we might be able to alter this approach but we haven't started down that path yet.]
Hints:
- Run the `:binary-compatibility:checkBinaryCompatibility` task before committing.
- If a public/protected method needs a new parameter, keep the existing method and create an additional one with the extra parameter. Sometimes the old method should be `@Deprecated`.
- If you want to rename a method, keep the old one and (if appropriate) deprecate the old one rather than just rename the existing one.
- If the return type of a method changes but nothing else, consider creating a bridge method - the build is set up to use a `Bridger` utility to do this for `$$bridge` methods.
- If the change can't be totally hidden, start a discussion in the dev/users mailing list as appropriate to investigate usages of the API by others.
- If the change can't be totally hidden, do mark the related JIRA issue (create one if needed) with the `breaking` label.
- If the change can't be totally hidden, do add a little summary/migration note in the relevant release note(s).
Checkstyle
TBD
Codenarc
TBD
Coverage
TBD