Fixed issue #1779 about compatibility with Gradle dependency verification. Previously it was failing with "Failed to create MD5 hash for file".

[AlexanderBartash]

Pull Request Details

I recommend to review this PR not by commits, but all of them together, because in the last few commits I have reverted a lot of code, which I added initially, while trying different approaches.

Combines #1782 #1783 & #1785 and adds another performance improvement. Recommended to review by commits.

Description

See the comment in LocalIvyArtifactPathComponentMetadataRule.kt file, it explains what was done pretty extensively.

~ExtractorTransformer now pre-creates Ivy XML files in the extracted IDE location, which makes it unnecessary to load all IDE plugins, resolve their location, create Ivy XML files on every build thereafter.~

~Potentially this is a breaking change because bundledPlugin & bundledModule dependencies now live in a separate repository created by IntelliJPlatformDependenciesHelper#registerIntellijPlatformIvyRepo That repository is not customizable by the user.~

Related Issue

No issue.

Motivation and Context

Life is short.

How Has This Been Tested

Tests, manually. On my project also on https://github.com/InSyncWithFoo/ryecharm

Types of changes

• [ ] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• [x ] I have read the CONTRIBUTING document.
• [ x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x ] I have included my change in the CHANGELOG.
• [ ] I have added tests to cover my changes.
• [ x] All new and existing tests passed.

[AlexanderBartash]

I think I have finally made it all work, but it seems that tests on windows fail randomly. I've seen this error first on Gradle 8.2 Win, then on Gradle 8.10.2 Win, now it is back on 8.2 Win.

I do no see how my changes could have caused this.

There seems to be an open bug https://youtrack.jetbrains.com/issue/KTIJ-893

org.gradle.testkit.runner.UnexpectedBuildFailure: Unexpected build execution failure in C:\Users\RUNNER~1\AppData\Local\Temp\tmp12965048409070354875 with arguments [-Dorg.gradle.kotlin.dsl.scriptCompilationAvoidance=false, verifyPluginProjectConfiguration, --stacktrace, --configuration-cache]

Output:
Calculating task graph as no configuration cache is available for tasks: verifyPluginProjectConfiguration

> Configure project :
Kotlin DSL property assignment is an incubating feature.
e: file:///C:/Users/runneradmin/AppData/Local/Temp/tmp12965048409070354875/build.gradle.kts:1:1: Cannot access implicit script receiver class 'org.gradle.api.Project'. Check your module classpath for missing or conflicting dependencies
e: file:///C:/Users/runneradmin/AppData/Local/Temp/tmp12965048409070354875/build.gradle.kts:8:1: Function invocation 'version(...)' expected
e: file:///C:/Users/runneradmin/AppData/Local/Temp/tmp12965048409070354875/build.gradle.kts:8:1: Unresolved reference. None of the following candidates is applicable because of receiver type mismatch: 
public infix fun PluginDependencySpec.version(version: String?): PluginDependencySpec defined in org.gradle.kotlin.dsl
public infix fun PluginDependencySpec.version(version: Provider<String>): PluginDependencySpec defined in org.gradle.kotlin.dsl
e: file:///C:/Users/runneradmin/AppData/Local/Temp/tmp12965048409070354875/build.gradle.kts:16:1: Unresolved reference. None of the following candidates is applicable because of receiver type mismatch: 
public fun Project.kotlin(configure: Action<KotlinJvmProjectExtension>): Unit defined in org.gradle.kotlin.dsl
public fun DependencyHandler.kotlin(module: String, version: String? = ...): Any defined in org.gradle.kotlin.dsl
public fun SourceSet.kotlin(configure: Action<SourceDirectorySet>): Unit defined in org.gradle.kotlin.dsl
public fun PluginDependenciesSpec.kotlin(module: String): PluginDependencySpec defined in org.gradle.kotlin.dsl

[AlexanderBartash]

I am done with this PR, I am not planning to change anything, unless there is a feedback. I tested this very extensively on my project on both linux and windows. Also I used this to build https://github.com/InSyncWithFoo/ryecharm on linux, it works.

[AlexanderBartash]

Rebased on HEAD. Also reverted one change:

Revert prefixing local groups with "com.jetbrains.localhost-only" because group names are hardcoded in the IDE https://github.com/JetBrains/intellij-community/blob/c8ba8401f73488f966b5ed5b5c5afaa38a9bcbdf/plugins/devkit/intellij.devkit.gradle/src/IntelliJPlatformAttachSourcesProvider.kt#L64-L67 AlexanderBartash 5 minutes ago f0bb8cc0

[AlexanderBartash]

Rebased.

[AlexanderBartash]

Rebased on the latest, including the not yet merged #1785 (because tests in master are broken). Also created a new implementation for resolving relative paths, because apparenyly we have to support RepositoriesMode.FAIL_ON_PROJECT_REPOS. The essence of it is described in this file

[AlexanderBartash]

Fixed issues on Windows. The failed tests on OSX are not related to this PR, see https://github.com/JetBrains/intellij-platform-gradle-plugin/pull/1792#issuecomment-2408716496

[AlexanderBartash]

Pushed 1 commit because I realized that there is a setting RulesMode.FAIL_ON_PROJECT_RULES just like RepositoriesMode.FAIL_ON_PROJECT_REPOS. The commit message pretty much explains it:

Refactored the logic to use the relative paths only if RulesMode.PREFER_PROJECT mode is used, because we can not use a project level ComponentMetadataRule with RulesMode.PREFER_SETTINGS or RulesMode.FAIL_ON_PROJECT_RULES. Added some logging and comments. Added new integration tests to make sure RepositoriesMode.FAIL_ON_PROJECT_REPOS & RulesMode.FAIL_ON_PROJECT_RULES are supported. AlexanderBartash 2 minutes ago a47b0b4a