Hi, did anyone experience slower builds after tran...

# gradle

[Mario Loncar]

Hi, did anyone experience slower builds after transitioning to convention plugins?

[Vampire]

Probably depends on the "from where" and in which situation.
If you for example have them in buildSrc or an included build, then they have to be built first of course unless they are up-to-date, so a clean build might be a bit slower.
Also if you have several convention plugins and in some project apply one in other the other, and you have all convention plugins in buildSrc or in the same project in an included build and change anything in the plugin project, then all tasks will be out-of-date as their classpath did change.
But even in all these cases, the slowdown should usually not be "that" significant.
So heavily depends on the concrete situation and the actual slowdown you are perceiving.

[Vampire]

Besides that your question per-se does not seem to be Kotlin-related, so would be off-topic here. ;-)

[Mario Loncar]

Thanks for the help 🙂

[Hristijan]

Just don't use the buildSrc folder at all as it recompiles almost on every run

[Vampire]

That is non-sense. 😉

[Vampire]

Or if it does, then you somehow cause this most probably with some setup you did.

[Vampire]

I also prefer using included builds, but that statement is just plainly wrong in 98,7% of the cases and the others are self-made

[Hristijan]

buildSrc is a separate build by itself that needs to be checked if it's up-to-date before executing the root build of the project, so i might have been wrong in using the correct word for my statement that it recompiles on every run, but it sure does have an overhead to check for the up-to-date of its files

[Vampire]

Which is quite minimal usually and not different to using an included build.

If you want to use convention plugins - which is highly recommended to centralize build logic - then the only choice to avoid that would be to build the convention plugins separately and publish them somewhere so that you can consume the ready-made binary result. And most often this is not worth the additional effort.

Also, much better to save that time is to make you build fit for configuration cache and use that, because if the configuration cache entry can be reused, all the phases up to the execution phase can be skipped, including building buildSrc or included plugin builds.