Use lazy configuration for classpath#77
Conversation
simonlebras
force-pushed
the
gradle-lazy
branch
from
50fc376 to
4cec3f8
Compare
simonlebras
force-pushed
the
gradle-lazy
branch
from
4cec3f8 to
70ae0d1
Compare
| withIndent { | ||
| add("configuration = this@%L.configurations.create(%S)\n", registerName(), isolationOptions.configurationName) | ||
| add("configuration.dependencies.add(dependencies.create(%S))\n", isolationOptions.coordinates) | ||
| add("this@%L.configurations.findByName(%S)\n", registerName(), isolationOptions.configurationName) |
There was a problem hiding this comment.
Fun fact, findByName() is not lazy either, you'll have to do the big try/catch dance around named().
Given that this code is only called when the task itself is configured and that if the task is configured, I would expect it to run, I'm not 100% sure what there is to gain here but if we really want to make things lazy, let's do this consistently?
There was a problem hiding this comment.
You're right 👍 I've updated the codegen with your suggestion.
I should have added more details in the description.
- when using
androidx.lint:lint-gradle, lint is complaining about generated code because ofcreatecalls, which requires using lint-baseline. - If the task is never executed,
configurationis never realized and stays lazy, even if the task is configured.
I do agree that the gain is small, so feel free to close the PR if you feel it's not worth it.
There was a problem hiding this comment.
I'm still mad that creating a Configuration is costly. It should really be a simple object, having to make everyone go through the hoops of creating lambdas is meh...
But the reality of today is that Provider<Configuration> is 1/10 of the RAM usage of a Configuration so let's go with that 👍
Thanks for the contribution 🙏
2 participants
Use
registerto create configuration