Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin dependencies not resolved in multi-module project #1196

Closed
brian-mcnamara opened this issue Nov 14, 2022 · 7 comments
Closed

Plugin dependencies not resolved in multi-module project #1196

brian-mcnamara opened this issue Nov 14, 2022 · 7 comments
Assignees
Milestone

Comments

@brian-mcnamara
Copy link
Contributor

Describe the bug
In a multi-module plugin where two modules have an intellij block (in my case, the top level module is for IC and the child-module is for IU), the child modules do not resolve the IJ plugin dependencies when loaded into intellij.

To Reproduce
https://github.com/brian-mcnamara/plugin-demo/tree/multi-module
Load that branch into IJ using the latest 1.10 snapshot. Notice the IU module does not list any dependencies (the javascript plugin should be there)

Expected behavior
If you use 1.9.0, you will see that IJ does resolve the dependencies correctly

Environment:

  • OS: macOS
  • Gradle IntelliJ Plugin Version 1.10.0-SNAPSHOT
  • Gradle Version 7.4.2

Additional context
Thread here: https://jetbrains-platform.slack.com/archives/CPL5291JP/p1668123533621749

@hsz
Copy link
Member

hsz commented Nov 14, 2022

@brian-mcnamara I cannot reproduce it when pointing to the latest 1.10.0-SNAPSHOT.
Both modules produce archives in build/distributions with to issues:
image

The IU module also contains relevant dependencies:
image

@brian-mcnamara
Copy link
Contributor Author

Hmm, I tried --refresh-dependencies again and still the same issue. Restarted IJ as well...
Screenshot 2022-11-14 at 11 39 34 AM

@brian-mcnamara
Copy link
Contributor Author

Ok cloned it on a different machine and everything is working. Wonder if there is another gradle cache somewhere effecting my main machine.

@hsz
Copy link
Member

hsz commented Nov 14, 2022

I guess so. There's --refresh-dependencies magic 🪄 switch available to invalidate the Gradle cache.

@hsz hsz added this to the next milestone Nov 14, 2022
@hsz hsz closed this as completed Nov 14, 2022
@brian-mcnamara
Copy link
Contributor Author

brian-mcnamara commented Nov 15, 2022

Still unable to fix this locally, tried clearing ~/.gradle/caches, clearing IJ indexes, using --refresh-dependencies. Will keep trying. I have been getting

Caused by: org.gradle.api.InvalidUserDataException: Cannot change dependencies of dependency configuration ':IU:compileOnly' after it has been included in dependency resolution.
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.preventIllegalMutation(DefaultConfiguration.java:1384)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.validateMutation(DefaultConfiguration.java:1344)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.extendsFrom(DefaultConfiguration.java:395)
	at org.jetbrains.intellij.IntelliJPlugin$configureSetupDependenciesTask$1$ideaConfiguration$1$1.invoke(IntelliJPlugin.kt:1475)
	at org.jetbrains.intellij.IntelliJPlugin$configureSetupDependenciesTask$1.invoke(IntelliJPlugin.kt:1477)
	at org.jetbrains.intellij.IntelliJPlugin$configureSetupDependenciesTask$1.invoke(IntelliJPlugin.kt:112)
	at org.jetbrains.intellij.IntelliJPlugin$inlined$sam$i$org_gradle_api_Action$0.execute(TaskContainerExtensions.kt)
	at org.gradle.api.internal.DefaultMutationGuard$2.execute(DefaultMutationGuard.java:44)
	at org.gradle.api.internal.DefaultMutationGuard$2.execute(DefaultMutationGuard.java:44)
	at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
	at org.gradle.api.internal.DefaultCollectionCallbackActionDecorator$BuildOperationEmittingAction$1.run(DefaultCollectionCallbackActionDecorator.java:110)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:68)
	at org.gradle.api.internal.DefaultCollectionCallbackActionDecorator$BuildOperationEmittingAction.execute(DefaultCollectionCallbackActionDecorator.java:107)
	at org.gradle.internal.ImmutableActionSet$SetWithManyActions.execute(ImmutableActionSet.java:329)
	at org.gradle.api.internal.DefaultDomainObjectCollection.doAdd(DefaultDomainObjectCollection.java:262)
	at org.gradle.api.internal.DefaultNamedDomainObjectCollection.doAdd(DefaultNamedDomainObjectCollection.java:113)
	at org.gradle.api.internal.DefaultDomainObjectCollection.add(DefaultDomainObjectCollection.java:256)
	at org.gradle.api.internal.DefaultNamedDomainObjectCollection$AbstractDomainObjectCreatingProvider.tryCreate(DefaultNamedDomainObjectCollection.java:944)
	... 177 more

Which I wonder if that is to be conserned with

@hsz
Copy link
Member

hsz commented Nov 16, 2022

I've reproduced the missing dependencies issue and sent the fix – it's now available as a snapshot.

@brian-mcnamara
Copy link
Contributor Author

Looks good! Thanks for finding the repo, I tried for a while on the machine that worked without success.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants