Best of both worlds between "buildSrc" and JAR

Help/Discuss
1

Hi,

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?

Thanks,
Olivier

2

Why is that? Have you profiled it? Sounds very high.

You have several options:

  • use TestKit to run your build with the version of the plugin currently under development
  • do what you described, but automate the copying of the jar to the correct location
  • copy the plugin code back to buildSrc while you work on the fix. When the fix is ready, copy back
3

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.

4

It will become more flexible in the future, but for now the options listed above are the ways you can go.