@sterling It’s a mix of a few languages, but the bulk of it is pure Java (currently compiling/targeting Java 8). There’s some Groovy used on the testing side, but nothing really on the production side. No annotation processing to worry about (whew). Java’s used for everything from the back-end server processes that run (JBoss/Tomcat) to this product’s previous front-end (applets, which are still supported, but the new front-end is HTML-based).
Currently, I’m using parallel, configure on demand, and the daemon. This is using the local cache - I’ve experimented with the remote cache enough to know it works, but I haven’t stressed it any.
I’ve done some preliminary testing with the remote build cache, using a plain Artifactory repo, but that’s not a terribly ideal solution - I’m trying to push the ball forward on something like Gradle Enterprise, something that has cache expiration policy, etc. But even with just the local build cache, there’s still some really nice wins. One example is branch switching. There are often multiple versions that require support (think service packs), and it’s not unusual to switch back and forth between versions using Git branching to accomplish this. With a local build cache, the recompilation costs around this are extremely minimal.
I haven’t experimented with creating custom cacheable tasks yet. For my use case, thankfully, everything on the path of ‘gradlew build’ so far is a case where you all already did the hard work.