Use single skiko-awt-runtime dependency on Desktop#2806
Use single skiko-awt-runtime dependency on Desktop#2806
Conversation
|
After writing Release Notes, I'm now thinking whether we should introduce |
| implementation(project(":collection:collection")) | ||
| implementation(libs.skikoAwtRuntime) | ||
| implementation(project(":collection:collection")) | ||
| implementation(project(":compose:desktop:desktop")) |
There was a problem hiding this comment.
Can we rename this module to compose:ui-awt?
There was a problem hiding this comment.
Could you please elaborate which exactly module you are proposing to rename?
There was a problem hiding this comment.
- rename
:compose:desktop:desktoptocompose:ui-awt(because it belong more toui, and similar toui-uikit) - remove any dependencies from
ui-awtexcept skiko - add
ui -> ui-awtdependency to hide this module from users (see my other comment)
There was a problem hiding this comment.
Does that mean that every library would have it as dependency, I've assumed we don't want this.
There was a problem hiding this comment.
I've assumed we don't want this.
Probably we want, because the org.jetbrains.skiko:skiko on the desktop target always assumes that the runtime dependency is present, can't work without them, and can't use something different. The org.jetbrains.skiko:skiko-awt-runtime dependency itself still doesn't point to a specific OS.
There was a problem hiding this comment.
Because of that, maybe we even don't need extra dependencies in Compose, and just make org.jetbrains.skiko:skiko -> org.jetbrains.skiko:skiko-awt-runtime in the desktop target in Skiko?
| implementation(project(":collection:collection")) | ||
| implementation(libs.skikoAwtRuntime) | ||
| implementation(project(":collection:collection")) | ||
| implementation(project(":compose:desktop:desktop")) |
There was a problem hiding this comment.
Can we don't require users to depend on this explicitly, and add transitive dependency ui -> ui-awt in desktopMain?
So, when users use the CMP plugin and compose.ui, they receive the right dependency.
| // during resolution, without affecting what gets published | ||
| project.configurations.configureEach { configuration -> | ||
| if (configuration.isCanBeResolved) { | ||
| configuration.resolutionStrategy.dependencySubstitution { |
There was a problem hiding this comment.
Can we use dependencyConstraints as in the CMP plugin to be consistent in the logic?
There was a problem hiding this comment.
Unfortunately, not.
Dependency constraints are propagated to published artifacts when configuration is consumable, and it is.
This means that all users will get linux/x86 requirement, if we are building on such a machine.
That's the best solution I've come up so far.
There was a problem hiding this comment.
Does this mean that we also need to use dependencySubstitutution in the plugin, otherwise libraries built with "Compose Multiplatform plugin" have this constraint?
There was a problem hiding this comment.
These constraints are only applied to skiko-awt-runtime module, and it is only added as dependency in applications, it is not included in libraries' dependencies. This works so far. And there is a property to disable this behavior completely.
If we rework dependency as suggested in another comment, add skiko-awt-runtime will be added to all libraries, than it might be an issue.
There was a problem hiding this comment.
I thought about it a little, and I see that if want to implement hiding this dependency from users (I see that it is beneficial), we can:
- use
dependencySubstitututionin the Gradle plugin - don't publish any additional modules on Compose side
- and it seems there is no point in
skiko-awt-runtime, and we can apply dependency substitution on theskikoartifact itself? If this is true, we can remove this artifact from Skiko publication?
There was a problem hiding this comment.
use dependencySubstitutution in the Gradle plugin
It looks like from user perspective it works the same? I.e. it allows running applications, and doesn't add anything to the library publications?
There was a problem hiding this comment.
If we rely on dependencySubstitution, we introduce hard dependency on Compose Gradle plugin.
This will limit us in the future in supporting other build systems.
Current proposed approach with skiko-awt-runtime is less limiting, as the required attributes can be provided manually. Well, after writing this, I realize that there is still a limitation and it is only marginally better.
| // during resolution, without affecting what gets published | ||
| project.configurations.configureEach { configuration -> | ||
| if (configuration.isCanBeResolved) { | ||
| configuration.resolutionStrategy.dependencySubstitution { |
There was a problem hiding this comment.
resolutionStrategy is local logic that affects only this project. If it's intended, please make it more explicit + link/explanation in comments how it's resolved for published artifacts
There was a problem hiding this comment.
Direct :compose:material:material dependency is still here, so CMP-5990 won't be resolved
3 participants
Describe proposed changes and the issue being fixed
Fixes CMP-9175 Introduce a single desktop dependency for all platforms
Testing
On desktop target, replacing the
compose.desktop.currentOswithorg.jetbrains.compose.desktop:desktop:1.11.0-alpha04should work without any other changes on all OSRelease Notes
Migration Notes - Desktop
org.jetbrains.compose.desktop:desktopnow depends on universalorg.jetbrains.skiko:skiko-awt-runtimeartifact, which is resolved to a platform specific artifact using Gradle attributes