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

Fix fastutil shadowing #3476

Merged
merged 3 commits into from Jan 30, 2024
Merged

Fix fastutil shadowing #3476

merged 3 commits into from Jan 30, 2024

Conversation

whyoleg
Copy link
Contributor

@whyoleg whyoleg commented Jan 29, 2024

Fixes: #3329 (comment)

I've updated the description of the fix in files, where the workaround is applied.

Also there are two changes in CLI integration tests:

  1. set isTransitive = false when building shadowJar which is used as pluginsClasspath in CLI - this way we can better control/understand which dependencies are provided to CLI. This will help to find issues with missing dependencies in future.
  2. support for running tests with K2 with property - this was done to correctly test, that the the current fix works.

If needed, I can split CLI integration tests changes to separate PR.

* additionally support running CLI tests with K2
dokka-integration-tests/cli/build.gradle.kts Outdated Show resolved Hide resolved
dokka-integration-tests/cli/build.gradle.kts Outdated Show resolved Hide resolved
Comment on lines 113 to 142
// configuration for dependencies which we need to replace with original ones because `kotlin-compiler` minimizes them
val shadowOverride: Configuration by configurations.creating {
attributes {
attribute(Usage.USAGE_ATTRIBUTE, project.objects.named(Usage::class.java, "java-runtime"))
}
}

dependencies {
shadowOverride(libs.fastutil)
}

val shadowDependenciesJar by tasks.registering(ShadowJar::class) {
group = "shadow"
description = "Create a shadow jar from dependencies without fastutil"

archiveClassifier.set("dependencies")
destinationDirectory.set(project.layout.buildDirectory.dir("shadowDependenciesLibs"))

// we need to create JAR with dependencies, but without fastutil,
// so we include `runtimeClasspath` configuration (the same configuration which is used by default `shadowJar` task)
// and include `fastutil` from the result
configurations = listOf(project.configurations.runtimeClasspath.get())
exclude("it/unimi/dsi/fastutil/**")
}

tasks.shadowJar {
// override configurations to remove dependencies handled in `shadowJarDependencies`
configurations = emptyList()
from(shadowOverride, shadowDependenciesJar)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this code is duplicated - should, or could, it be extracted into a convention plugin?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the code is the same, but it's intentional at my side. While for now the issue is the same for both modules (with fastutil only); symbols and descriptors dependencies are rather different and even use different versions of Kotlin Compiler under the hood. So if something will change in future (in our build or in dependencies) it will be easier to fix.
This is rather a workaround for now than a long term solution, and we hope it will be fully removed for symbols module when Standalone Kotlin Analysis API will become stable

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right, yes it makes sense that not everything will be duplicated. But the shadowDependenciesJar task and shadowOverride will be the same in each subproject? Could those definitions be moved to the existing dokkabuild.publish-shadow.gradle.kts plugin, and then each subproject would have independent workarounds, and add their own dependencies and exclusions?

E.g. add this to the convention plugin:

// dokkabuild.publish-shadow.gradle.kts

// ...

val shadowOverride: Configuration by configurations.creating {
  // ...
}

val shadowDependenciesJar by tasks.registering(ShadowJar::class) {
  //...
}

tasks.shadowJar {
    // override configurations to remove dependencies handled in `shadowJarDependencies`
    configurations = emptyList()
    from(shadowOverride, shadowDependenciesJar)
}

And then each subproject could set up things differently:

dependencies {
    shadowOverride(libs.fastutil)
}

tasks.shadowDependenciesJar {
    exclude("it/unimi/dsi/fastutil/**")
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you - I just wanted to clarify about what I think could be deduplicated, but perhaps it's not worth it :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the shadowDependenciesJar task and shadowOverride will be the same in each subproject?

Who knows? :)
On current moment current workaround works for fastutil and we have no idea now, how other things will work.
So here Im more in favour of copy-paste workaround instead of generalising workaround based on one use-case.
Will wait for other reviews on this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Oleg here 👍 I think it would be mega useful to extract this logic into a convention plugin if we had more than one use case for it that we expected to have long-term

This particular hack, however, ideally should only stay in K1 (if at all), and the K2 analysis shouldn't have this problem to begin with. We're waiting for K2's Analysis API to set up proper artifact publishing, and hopefully after KT-61404 is implemented, we'll be able to remove this workaround from the analysis-kotlin-symbols build scripts

So I wouldn't generalize this logic now, and would wait until we stumble upon this problem again (which might be never, but might be next month)

Copy link
Member

@IgnatBeresnev IgnatBeresnev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's actually not as scary as I thought it would be 👍

…otPackageClass.kt

Co-authored-by: Ignat Beresnev <ignat.beresnev@jetbrains.com>
@whyoleg whyoleg merged commit 3c989c1 into master Jan 30, 2024
11 of 12 checks passed
@whyoleg whyoleg deleted the fix-fastutil-master branch January 30, 2024 18:45
@IgnatBeresnev IgnatBeresnev added this to the Dokka 1.9.20 milestone Jan 31, 2024
IgnatBeresnev pushed a commit that referenced this pull request Jan 31, 2024
* support running CLI tests with K2
* explicitly control dependencies in CLI integration tests

---------

Co-authored-by: Ignat Beresnev <ignat.beresnev@jetbrains.com>
(cherry picked from commit 3c989c1)
vmishenev pushed a commit that referenced this pull request Mar 20, 2024
* support running CLI tests with K2
* explicitly control dependencies in CLI integration tests

---------

Co-authored-by: Ignat Beresnev <ignat.beresnev@jetbrains.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Dokka failing for email-like string in angle brackets
4 participants