Skip to content

Package kotlinx.coroutines.debug is split between two distinct artifacts #3128

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

Open
zajac opened this issue Jan 10, 2022 · 7 comments
Open
Assignees

Comments

@zajac
Copy link

zajac commented Jan 10, 2022

Subj prevents us from depending on both of them in any JPMS module and even from having both of them on the module-path simultaneously. Maybe there are other instances of split-package in coroutines lib, which also need to be addressed.

@qwwdfsad
Copy link
Member

We indeed have a split package:

  • One in kotlinx-coroutines-debug module that has a user-facing [experimental] API for dynamic debug probes attach/detach and programmatic work with a debugger.
  • One in kotlinx-coroutines-core. This part is not user-facing, but stable -- it is used by both IDEA and the upcoming Android Studio debugger to obtain information about coroutines, and cannot be changed in a backwards-incompatible manner without breaking coroutine debugger in existing IDEAs.

The problem seems significant as it prevents us from properly adopting JPSM with the only potential solution to rename the package in kotlinx-coroutines-debug

@qwwdfsad
Copy link
Member

Meanwhile, it seems like I've found a workaround for JPSM-projects: the project has to declare an additional module, e.g. fleet-coroutines-debug that has to repackage, shade and export kotlinx-coroutines-debug under a different root package (e.g. fleet.kotlinx.coroutines.debug). All other modules should depend on the artificial "debug" module for debug capabilities

@zajac
Copy link
Author

zajac commented Jan 10, 2022

Maybe we can do that once and for all JPMS projects? To have a separate artifact that does particularly that, which is not compatible with the original one, but allows it to be required by JPMS modules

@zajac
Copy link
Author

zajac commented Apr 28, 2022

when is 1.7 scheduled? may we have some artifact earlier than that? Kinda critical for us.

@qwwdfsad
Copy link
Member

We already discussed it, it won't be "fixed" in 1.7.0, because such change should be processed with proper deprecation cycle; unfortunately, we cannot just change the package, neither we are going to maintain multiple artifacts that differ only in package and open the door to JAR hell.

If it is critical, I suggest applying the workaround I've provided above

@big-andy-coates
Copy link

+1 on a fix for this please.

@qwwdfsad qwwdfsad removed the for 1.7 label Dec 7, 2022
@qwwdfsad
Copy link
Member

https://youtrack.jetbrains.com/issue/KTIJ-24102/Change-coroutine-debugger-implementation-to-use-a-new-package issue to keep track of, this is the pre-requisite to split-package removal

@sellmair sellmair self-assigned this Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants