What gradle task does "Reload Gradle Project" / "Reload All Gradle Projects" run?
I've a peculiar scenario when I include a specific plugin in one of my modules build.gradle ( id 'gg.jte.gradle' version '3.1.9') , “Reload All Gradle Projects” starts exploding on the project. All other gradle tasks (build/etc) work normally. It's somewhat confusing because the actual build step it attempts to run where it explodes is collectReachabilityMetadata which is related to GraalVM and none of my projects, settings or anything at all is in any shape related to GraalVM. I'm trying to reproduce it from command line gradle but I can't figure out the exact gradle command that IntelliJ runs. From IntelliJ log I know it initializes a number of its own gradle scripts for this operation such as:
--init-script /private/var/folders/0v/8wd5lgg15wn5w57hynyst82m0000gq/T/ijIdeaPluginConfigurator1.gradle --init-script /private/var/folders/0v/8wd5lgg15wn5w57hynyst82m0000gq/T/ijMapper1.gradle -Didea.gradle.download.sources=false -Didea.sync.active=true -Didea.resolveSourceSetDependencies=true -Porg.gradle.kotlin.dsl.provider.cid=431244698792750 -Pkotlin.mpp.enableIntransitiveMetadataConfiguration=true --init-script /private/var/folders/0v/8wd5lgg15wn5w57hynyst82m0000gq/T/ijInit1.gradle -Didea.active=true -Didea.version=2024.1 -Didea.vendor.name=JetBrains
but i can't figure out the actual gradle task it executes.
Gradle Version 8.7, Apple Silicon (aarch64)
Build #IC-241.14494.240, built on March 28, 2024
Runtime version: 17.0.10+8-b1207.12 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
The actual error it gives me is:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create task ':services:workbook-svc:collectReachabilityMetadata'.
Cannot set the value of task ':services:workbook-svc:collectReachabilityMetadata' property 'metadataService' of type org.graalvm.buildtools.gradle.internal.GraalVMReachabilityMetadataService using a provider of type org.graalvm.buildtools.gradle.internal.GraalVMReachabilityMetadataService.
请先登录再写评论。
Just to follow up: I've resolved my original issue of why GraalVM gradle tasks were appearing. One of the micronaut plugins in the updated framework started including GraalVM gradle plugin by default. However, I'd still love to know what IntelliJ executes when it refreshes projects for future debugging.
Aguselnikov I'm afraid, there is no direct equivalent for IDEA's Import/Sync in Gradle.
IDEA runs a unique set of commands that allows it to extract data from Gradle Project, that it needs to convert Gradle's Project Structure to its' own internal model.
Note though, while the Import/Sync operation is unique to IDEA it still relies on the same basic Gradle machinery and the errors that it returns during the Import/Sync can be approached as regular Gradle errors.
Do not hesitate to let us know if you encounter any such errors - we will be happy to help!
Roman Vatagin
Right that's what I worked out so far. The issue is that the error in question was happening ONLY during IntelliJ sync and not during any other gradle task that exists whether on module level or whole Project level. That's what made it somewhat puzzling.
Aguselnikov This is very much understandable!
That's why if the issue only affects Sync/Import it's best to report it to us (with a reproducer Project, if possible), as the issue would be investigated most efficiently from our end.
We just ran into this in our multi-project monorepo. The problem started when I added the Micronaut openapi plugin in one subproject. The fix for us is to make sure all subprojects used the same set of gradle plugins:
https://github.com/gradle/gradle/issues/17559
Can confirm we're also experiencing this repeatedly on a monorepo project we are converting to gradle multi-project. Everything works fine invoking gradle from CLI. But unable to “Sync” IntelliJ w/ gradle due to constant “Cannot set the value of task ‘….’ property ‘….’”
Willismorse James Hardwick Would it possible to share an affected Project?
We have not yet reproduced an issue like that on our end, it may require a very specific configuration.
Having a reproducer Project would really help to move the investigation forward.
Roman Vatagin Unfortunately, this is a large closed repo and I don't have a reproducible portable codebase example.
Willismorse Would it be possible to only share the Project's build scripts (preserving the directory structure)?
If that is not possible either, set Gradle logging for Project to
INFOlevel, by adding the following line togradle.propertiesfile:Run a Sync and share the full output from the Build Tool Window (feel free to redact any sensitive data).
You can share it privately using our upload service - please post the Upload ID here.
Roman Vatagin I think I can whip up a sample that reproduces it. Will try and do so today and if not, then this weekend perhaps.