I think something went wrong with the stately publ...
# touchlab-tools
I think something went wrong with the stately publishing: • https://repo1.maven.org/maven2/co/touchlab/stately-concurrency/2.0.0/ • There are artifcats dated on epoch • It’s not listed on maven https://mvnrepository.com/artifact/co.touchlab/stately-concurrency • Somehow renovate picked it up but ultimately it fails when building ios, complaining about stately-common
Copy code
> Task :shared:library:kspKotlinIosSimulatorArm64 FAILED
e: Could not find "co.touchlab:stately-common" in [/Users/ph1b/repos/yazio/apps, /Users/ph1b/.konan/klib, /Users/ph1b/.konan/kotlin-native-prebuilt-macos-aarch64-1.9.10/klib/common, /Users/ph1b/.konan/kotlin-native-prebuilt-macos-aarch64-1.9.10/klib/platform/ios_simulator_arm64]
Ah. Will take a look. We updateur publishing on other libraries but stately is still using our older process. There's not really anything custom, but there does seem to be something weird
As a shortcut I did a migration from the stately lock to an atomicfu reentrant lock. Do you think there is a functional difference?
Probably not? I haven't looked at atomicfu in a while, but it's on my todo list to check in on it again.
I'm deeply confused by that project. If something wants me to add a Gradle plugin, I'm really searching for a reason why ^^
I use atomicfu without the Gradle plugin. There are quite a few gaps in the documentation, but from what I can tell, it's only necessary if you want to remove the runtime dependency from JVM targets. I looked into it recently and it took a while to figure out how to apply the plugin with the newer plugin DSL and version catalogs. Ultimately I discovered there are usages in my app it doesn't support, and it also doesn't work with Android targets. So I'm continuing to use atomicfu sans Gradle plugin. I wish the docs were more clear that this is a valid way to use the library.
BTW, stately publishing update. https://github.com/touchlab/Stately/releases/tag/2.0.2. Should be OK now. Gradle 8+ apparently doesn't like whatever we were doing a few years ago.
On atomicfu, I need to take a look. A few years back I soft-archived Stately assuming atomicfu would be the thing to move to, but I guess some folks liked the stately versions of the structures, so we kept it. When it was basically zero overhead it was fine to just deploy once in a while, but this last publishing issue was rough. In the "post-strict-memory" world, stately's core purpose is kind of gone, although I did add basic concurrent collections implementations. Now that publishing is "working" I'm not in a huge rush to archive the project, but it definitely needs to be bug fixes only.
👀 1