As initially <reported in the EAP channel>, the Ko...

# gradle

[ianbrandt]

As initially reported in the EAP channel, the Kotlin Gradle Plugin in 2.0.20 broke the Dependency Analysis Gradle Plugin's ability to analyze dependency configurations for source sets/compilations that are associated with another (useful for example to give integration tests access to internal code in the 'main' source set, as is done automatically for the built-in 'test' source set). KGP now mutates the dependency configurations of associated compilations (e.g. integrationTestImplementation, integrationTestCompileOnly, integrationTestRuntimeOnly) to add the corresponding dependencies from the associated-with compilation, which undermines DAGP's ability ascertain and thereby analyze the dependencies that were user-declared.

The corresponding issue, KT-70871, has been closed as "As Designed", but with no suggestion as to how the lost functionality could be restored given the new design, and follow-up questions asked after the ticket was closed have so far gone unanswered. I'm re-raising the issue here given 2.0.20 is no longer in EAP, and also for more targeted visibility.

I find the Dependency Analysis Gradle Plugin vital to maintaining correct dependency configurations at scale, and thereby to sustaining reliable builds for large, multi-module projects. Would someone at JetBrains consider re-opening KT-70871 to cover a different design for KGP's handling of associated compilations, or would anyone have an idea for how DAGP's functionality could be sensibly restored for Kotlin 2.0.20+ as is?

[tapchicoma]

I will come back to this topic next week

[tapchicoma]

Small update on this topic:
• I am pushing IDE team to add support for -Xfriend-path argument, so we could add some DSL for it in KGP
• I am looking on the way how DAGP could support KMP projects and associateWith part which used widely in it

[ianbrandt]

Thank you for the update, Yahor. I see 2.1.20-Beta1 is out. It sure would be great if we could restore DAGP analysis of our custom test suite dependencies with 2.1.20. 🤞

[tapchicoma]

Update regarding -Xfriend-path support - Language design team first wants to redesign this compiler argument so no IDE or official DSL support in the nearest releases until this redesign will be done.

Overall it is being considered as internal compiler argument providing a workaround for main -> test sources visibility and that it should not be used outside 🤷‍♂️

[ianbrandt]

@tapchicoma, Thank you for that update. I confess I’m not entirely following how all that relates to a need to mutate Gradle configurations when there are associated compilations, but I trust that you do. I do want to ask, would it be possible to reopen https://youtrack.jetbrains.com/issue/KT-70871 so people can vote and follow the status of this, or is there another issue we should follow that covers re-enabling analysis of test suite dependency declarations?

[ianbrandt]

Thank you for re-opening KT-70871. I added an additional comment regarding the impact of it.

[tapchicoma]

Update on -Xfriends-path - we've started the discussion how to approach it and we've have an prototype which avoids this argument. Now we want to verify this idea with a compiler team. Will update once we will have new information.

[ianbrandt]

In case others (@tony 😉) want to vote for or follow them, these appear to be the -Xfriend-path related issues:
• https://youtrack.jetbrains.com/issue/KT-62687/Stabilize-friends-modules-compiler-argument
• https://youtrack.jetbrains.com/issue/KT-62688/Provide-a-Kotlin-plugin-DSL-to-configure-friend-modules
• https://youtrack.jetbrains.com/issue/KTIJ-31881/Support-Xfriend-path-compiler-argument-in-the-Kotlin-plugin