This message was deleted.

I don't know, but it probably would be pointless. A CC entry is tied to the tasks you request to be executed and for that skips all the configuration and directly jumps to the execution of the tasks. But IDE sync is different, it does not execute tasks but just gets information about the project. What will improve and speedup IDE sync afair will be project isolation which will then allow the sync to be done for multiple projects in parallel.

IDE does run tasks though, those provide the data for IDE import. Essentially the configuration cache is what IDE needs to import when you think about it.

No, the configuration cache contains tasks and their properties, not the information the IDE needs.

It's true that I'm thinking of the specific way IntelliJ IDEA imports Gradle projects. That works by running tasks that give it the description of the tasks and their properties and how the modules are structured and all, which is all part of configuration.

That works by running tasks that give it the description of the tasks and their properties and how the modules are structured and all

No, it does not.

I'm not saying it's executing the

tasks

task, but some Gradle tasks are being run during sync

Yeah, as I said, something Kotlin specific. Use Groovy DSL build scripts and there will be no task.

Same thing with Groovy DSL

Then that obviously changed. It was not the case in the past. But anyway. that task is not outputting anything anyway, it just prepares something, no idea what. But the information IntelliJ needs, it gets through the tooling API.

Why not?

Otherwise it would be skipped

That's not necessarily true

Well, it is written as "limitation" and with the words "not yet". But that does not mean it ever will, there were similar "limitations that will be removed in a future version" that never were and finally just the promise removed from the docs. 🤷‍♂️

Yeah, and that's why I was trying to understand the reason behind it

as I understand it's because there's no API to get the description without configuring the task https://github.com/gradle/gradle/issues/9823

But that would be part of the configuration cache, wouldn't it?

interesting question, I don't know if the name and description are stored in the configuration cache 🤔. I assumed it would only be task inputs and outputs. In any case, even if they were I don't think there's any reasonable way to read values from the configuration cache.

The cache should contain everything that's done during configuration so that it can restore it later

I don't think it is about inputs and outputs, but about the whole state of the task class

I'd expect it's not just the tasks, but the whole configuration (configurations, sourcesets etc.) and that's the information IDE is using

by IDE you mean IntelliJ right? :) I don't know if other IDEs support Gradle quite as deeply

Why should it be more than tasks? At execution time tasks are executed, to tasks is what is saved and restored.

I know that IntelliJ dynamically builds and injects an init.gradle script in order to modify the build config, and fetch Gradle data. And because it's created dynamically and stored in a temporary file that often means Gradle needs to reconfigure.

There's no fundamental reason why configuration caching (CC) can't be applied to sync. However, the coarse-grained caching that CC currently uses makes it kind of pointless, as generally developers run a sync when one of the inputs into the IDE model has changed and so the cache entry will not be usable.

Great to hear! As for the coarse-grainess, we often have just one of a 100 modules configuration changed so CC would still be valid for the other 99 during sync. Or would it all get invalidated anyway?

Currently, CC is coarse-grained, so if 1 module changes and 99 stay the same, then everything is invalidated. Obviously, this isn't a great situation, but it was only intended to be a temporary one. Isolated projects (IP) basically takes CC and makes it fine-grained. So, when IP is enabled, then if 1 module changed and 99 stay the same, then only that changed module will be invalidated. For the other modules, the result would be reused from cache.

Oh! Now I understand, thanks for that context

Oh yeah, absolutely.