https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
til 1
c
What are your configuration times like at the moment?
z
depends, can be quite high when invalidating 
buildSrc
c
My opinion on this has shifted over time. For context I maintain a buildsystem for a Java project (with some limited JS components). The main repo is 360 kloc, from bare the config takes sub 60 seconds, and once everything is warm it’s sub 10s. I tried to go “full bore” configuration avoidance and you know what, I realized my time was much better spent working on integration/unit test runtimes, or even on kit assembly and improved incremental-ness. I think Gradle’s emphasis on configuration avoidance says a lot about whats important to their customers, but not necessarily much about its importance to any given build.
There’s also the problem that the necessary API changes needed to reach full config avoidance haven’t reached far enough in to the wider plugin ecosystem (or even the entire Gradle API last time I checked) to make it actually possible to achieve “full config avoidance”
j
I am not using 
configureEach
a lot because of that, if it should be used maybe getting a lint warning...
c
The biggest issue I see with the snippet is that its ascribing meaning to task names. A correctness problem probably trumps a performance problem. 😉
👍 1
z
agreed - we definitely need a lint warning to catch these issues
v
@Javi what do you use instead then? You should always use 
configureEach
. The problem in that blog post is not the 
configureEach
, but the unguarded 
matching
. To evaluate the condition, the tasks need to be realized. So if you do 
matching
directly on 
tasks
, each and every task needs to be realized.
j
Sadly the first one because I forget to add the configureEach because both gives the task in the lambda. Personally I think Gradle has an issue about default or intuitive things not being the recommended approach, overall in Kotlin
This is an example but I thought exactly the same when I saw that the properties should be set via 
someProp.set(…)
. A delegate or whatever which allows using 
someProp = …
should be great for example
I understand that this issue is because the intuitive things were the “previous mode” and it can't be removed or deprecated, so altering it can be difficult to be achieved by Gradle engineers without affecting a lot to everyone
v
Ah, misunderstood "because of that". I thought you do that intentionally because of the blog post you linked to. Right about the unlucky defaults. Unfortunately not easy to change. The legacy way was there first and thus convenience methods for it created. Now you cannot easily change that without breaking things.
👍 1
➕ 1
A delegate for the properties was also discussed already and there is even a lib for plugin authors providing that for their users, but you break provider chains with that, which is probably the main cause that is not built-in
j
Ah, sad 😢. Maybe with compiler plugins this can be improved, but this is not going to happen soon I guess
v
You might want to thumbs-up and follow this ticket: https://github.com/gradle/gradle/issues/9268
j
subscribed :) thank you 🙏
Open in Slack
PreviousNext
Powered by