I have a pretty complex plugin that is currently located in “buildSrc”, and which is working fine. Currently, it’s very convenient to modify it, since it’s (re)compiled on the fly automatically by Gradle as required. The problem is that this takes at least 10 seconds, even if there are no changes.
I know I could make a JAR out of it, and that starting the build would be much faster, however, I would when changes would be necessary, the naive workflow would be quite cumbersome and slow (modify, create JAR, copy JAR in place, start build) compared to the current one (modify, start build). Is there a better alternative than this naive workflow?
Is there way to decide at runtime whether to use the JAR or buildSrc? That would make things much easier, because then I could choose to use buildSrc during the development cycles, and when I am done, deploy the JAR and start to use it. However, it seems the handling of “buildSrc” is hard-coded in Gradle and cannot be modified. Or can it?
No, I didn’t profile it, but it doesn’t surprise me, since I don’t use the daemon due to a few issues with it, so a new VM is started each time. Then it needs to compile about 30 Groovy files.
I was hoping I could avoid copying and renaming files or directories. It is actually surprisingly inflexible from Gradle to unconditionally load from buildSrc, and that this name is hard-coded. I understand this mechanism has to be easy in the simple situations, but it would also make sense to be able to customize it, like with so many aspects of Gradle.
I will have a look at TestKit, thanks for your time.