Hi,
we have a (huge, deeply nested) project that needs to be build after a clean every time. No incremental builds! So far it was build using bash scripts/ANT/Maven. I got the task of rewriting everything in Gradle. The actual execution phase is on par with the previous (bash/ANT/Maven) solution. The problem is the initialization/configuration phase - which is much too slow.
I did a lot of performance tuning the last two weeks but I am pretty sure this is a dead end. I did improve configuration times quite a bit but it still takes much much too long. Even if I manage to cut it in half a couple of times (which I won’t), it is still too slow.
I hope the answers to my question will not try to convince me to speed up configuration phase
The previous bash/ANT/Maven solution basically has no configuration phase. It just executes compilers, copies files, etc., bare to the metal. It’s basically what you would do manually on a CLI, just automated.
The solution would be to do the same with Gradle and explicitly define the initialization and configuration phase and directly enter execution phase.
I did dig into the Gradle code (not just the API) and it seems pretty complex (although beautifully written). Still, due to the complexity I wonder what the best way would be to approach my goal.
Ideally I would import the entire Gradle codebase and have access to all internals. Instead of using build.gradle I would directly use Java to initialize and configure the Project objects before kicking off the execution phase. I would like to try this on a smaller mock project first and do extensive performance test - which I would report back.
Looking at the Gradle codebase it seems to be designed to keep people from doing this (why would you do that?). I am no Core Dev, so maybe I am mistaken.
I think the build.gradle is in itself a plugin that is applied to the correct object without calling apply by the bootstrap process. Maybe for my experiments you could suggest changes that allow me to directly write a plugin and convince the bootstrapper to use it directly without some ugly build.gradle script hack that calls my plugin.
Cheers,
Dieter
P.S.: Gradle is very flexible. That’s why I am really puzzled and confused to discover why you married build.gradle so tightly to the underlying project. For most users the build.gradle should offer a very nice and readable DSL which simplifies accessing the build-API for most standard builds - and the build.gralde and Groovy DSL (or Kotlin) does this very nicely. To force people to use build.gradle (at least in some minimal way) seems like a big mistake for many reasons.