https://kotlinlang.org logo
Join Slack
Powered by
Is it possible to log the qualified names of State...
# ballast
r
Is it possible to log the qualified names of State and Inputs by default? Currently the log (in Kotlin/JS at least) just contains things like:
Copy code
State changed: State(...)
Without the qualified name for State, its hard to distinguish which view model's state has changed.
c
Fully-qualified names on non-JVM targets require 
kotlin-reflect
, so it’s not planned. But you can set the tag on your logger which will give the distinction you need. For example, doing 
logger = ::JsConsoleBallastLogger
instead of 
logger = { JsConsoleBallastLogger() }
in the VM configuration (and make sure you’re also setting the VM name in 
withViewModel()
)
r
Thank you, I didn't notice the logger took the view name as a parameter.
OMG, so much better, lol :-)
c
Glad to help! And related, is there something in the documentation you were looking at, that was missing this info? I’ve tried to make sure the code snippets always included the logger with a tag (though admittedly the syntax isn’t always consistent, sometimes also using 
logger = { JsConsoleBallastLogger(it) }
)
r
I probably just missed it. I inject my own logger via DI so probably wasn't looking at the specific syntax in the docs as closely as I should have.
c
Yeah, you’ll want to inject a logger factory instead, so that each logger instance is unique to the VM
r
Yep, I did that: 
bind<BallastLogger> { factory { tag: String -> KermitBallastLogger(tag) } }
and then:
Copy code
bindProvider {
    BallastViewModelConfiguration.Builder()
      .apply {
        this += instance<Set<BallastInterceptor<Any, Any, Any>>>()
        logger = factory()
      }
  }
(this all Kodein-DI fwiw)
Works great!
The other thing that really helps with logging is the new 
data object
.
c
Oh, I’m so excited to try that one out, especially in JS which has default 
toString()
that is compeltely useless. I’m just now starting to make the updates to 1.8, but am having some Gradle issues that are slowing me down quite a bit
r
Yep I grew to hate 
[Object object]
🙂 Completely gone now.
What Gradle issues out of curiosity?
c
An error publishing another library of mine, Kudzu, which is a single Gradle module and dependency-free, which is usually pretty trivial to update. I think it’s actually an issue with Gradle 8 rather than Kotlin, but I was trying to get everything updated at once. The issue is related to the 
signing
plugin, needed for publishing to MavenCentral, and something’s not playing nicely with it:
Copy code
A problem was found with the configuration of task ':kudzu-core:signAndroidReleasePublication' (type 'Sign').
  - Gradle detected a problem with the following location: '/Users/cbrooks/Documents/git/github.com/copperleaf/kudzu/kudzu-core/build/libs/kudzu-core-5.0.0-SNAPSHOT-javadoc.jar.asc'.
    
    Reason: Task ':kudzu-core:publishAndroidDebugPublicationToMavenLocal' uses this output of task ':kudzu-core:signAndroidReleasePublication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
    
    Possible solutions:
      1. Declare task ':kudzu-core:signAndroidReleasePublication' as an input of ':kudzu-core:publishAndroidDebugPublicationToMavenLocal'.
      2. Declare an explicit dependency on ':kudzu-core:signAndroidReleasePublication' from ':kudzu-core:publishAndroidDebugPublicationToMavenLocal' using Task#dependsOn.
      3. Declare an explicit dependency on ':kudzu-core:signAndroidReleasePublication' from ':kudzu-core:publishAndroidDebugPublicationToMavenLocal' using Task#mustRunAfter.
I’ve basically got the exact setup from the Kotlin documentation and my google searches aren’t turning up anything helpful, so I’m not quite sure what the culprit is. But I haven’t dug very deeply yet
r
Ah yeah, I've had that before with some tasks that don't correctly declare their dependencies. The workaround is pretty simple, if you're ok with a workaround.
c
I can get it to work with manually declaring the 
mustRunAfter
blocks, as suggested in the logs. I’m hoping there’s a cleaner solution though. I’m also taking the time to look into migrating the 
buildSrc
logic into an included build
r
Copy code
tasks.named("publishAndroidDebugPublicationToMavenLocal") {
  dependsOn("signAndroidReleasePublication")
}
is a bit cleaner as it expresses the dependency relationship and allowing Gradle to infer the run order, rather than directly trying to change the run order.
It may be because the publication to maven local doesn't expect signed artifacts?
Oh the debug publication is depending on the release signing, that's weird
c
The local publication really shouldn’t be any different than publishing to a remote. It’s just copying files from a publication, vs sending HTTP POSTs for those same files
Yeah, there’s some other strange dependencies like 
compileTestKotlinIosX64
accessing 
signIosX64Publication
. I suspect the signing plugin is doing something like replacing the archive files with signed ones, and maybe something like my plugin ordering or the way I’m declaring my convention plugins is causing the explicit connections to not be expressed for the Kotlin build tasks
r
Do you have a signing block where you define what gets signed?
c
This is the convention plugin applying the maven-publish and signing plugins. It’s nearly identical to what’s described in the Kotlin docs except for how I provide the secrets
r
Do you want to sign debug outputs? Line 79 currently signs everything. Maybe change that to sign only release publications?
c
Seems reasonably, I’ll give that a try
I found a YouTrack ticket that seems to be getting at the root problem here, and added a comment with some of my own findings https://youtrack.jetbrains.com/issue/KT-46466
6 Views
Open in Slack
PreviousNext
Powered by