LocalIvyArtifactPathComponentMetadataRule

This comes into play only when org.gradle.api.initialization.resolve.RulesMode.PREFER_PROJECT (the default) is used in Gradle's settings.

Fixes relative URLs of dependencies from the local Ivy repository org.jetbrains.intellij.platform.gradle.extensions.IntelliJPlatformRepositoriesHelper.createLocalIvyRepository by appending the full absolute path. It is necessary only for Dependencies.BUNDLED_PLUGIN_GROUP and Dependencies.BUNDLED_MODULE_GROUP dependency types.

For Dependencies.BUNDLED_PLUGIN_GROUP and Dependencies.BUNDLED_MODULE_GROUP, we expect:

• "artifact" (org.jetbrains.intellij.platform.gradle.models.IvyModule.Artifact.name) is mandatory and contains only the name of the artifact (for example, a jar archive), without the extension.

• "url" (org.jetbrains.intellij.platform.gradle.models.IvyModule.Artifact.url) contains a path, relative to the platformPath (IDE), without the file's name. According to Ivy's documentation

  a URL at which this artifact can be found if it isn’t located at the standard location in the repository

  It may be not the best to field to put this into, but there is no alternative.

  The reason why we put the path into "url" is that the name shouldn't have it, because:

• Artifact name may come up in files like Gradle's verification-metadata.xml which will make them not portable between different environments.

• https://github.com/JetBrains/intellij-platform-gradle-plugin/issues/1778

• https://github.com/JetBrains/intellij-platform-gradle-plugin/issues/1779

• https://docs.gradle.org/current/userguide/dependency_verification.html

• Artifact name may also come up in Gradle errors, for example, if for some reason the artifact is not resolved. In that case, the artifact coordinates may look very weird like: bundledPlugin:/some/path/more/path/some.jar:123.456.789 For the same reason file extension is also stored in "ext".

• "ext" org.jetbrains.intellij.platform.gradle.models.IvyModule.Artifact.ext is an optional file extension, like "jar". It is optional only because files don't always have extensions. For directories, it would be "directory", but in this case, we never expect to have a directory, always only files.

Relative paths are better than absolute because if Gradle's dependency verification is used with metadata (for example, ivy.xml or pom.xml) files verification enabled, hashes of these files will be the same in different environments, despite that they're stored in different locations. If absolute paths are used, they will be mentioned in ivy.xml thus changing the hash on each env.

But since our local Ivy repository has an artifact pattern /[artifact] relative URLs won't work. See org.jetbrains.intellij.platform.gradle.extensions.IntelliJPlatformRepositoriesHelper.createLocalIvyRepository. That is why this class is needed.

This is called after Ivy XML metadata is already found and parsed, so all dependencies and publications are known, but not yet resolved on the file system, so we have a chance to fix the paths.

A separate note on org.gradle.api.artifacts.CacheableRule, since there is not enough information on it in the internet. First, see the comments in org.gradle.internal.resolve.caching.CachingRuleExecutor. I tried to debug it, and it seems like rule parameters are taken into account. It happens in org.gradle.internal.resolve.caching.CrossBuildCachingRuleExecutor.computeExplicitInputsSnapshot Which should mean that we can use the caching, because if the paths change, it should be re-evaluated.

See also