TBD•5mo ago

Blocker Adding `tbdex-kt` Support

Blocker Adding tbdex-kt Support

23 Replies

ALR•5mo ago

@techgirl1908 and @devRel - I'm working to get you tbdex-kt support in the new Kotlin TestSuite. I've hit a blocker that I understand, and am going to think about the quickest remediation paths I can take with the upstream teams to resolve this. Details here.

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

Yup now let’s fix it up nice 🙂

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

@chrisgiglio The problem is that adding tbdex as a dependency at all fails the Web5 tests. I gotta think on the quickest path for yall.

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

Where in this are you trying to pull tbdex-kt:0.8.0? To your 2). - they're not compile errors; they're runtime errors that occur even with no code changes simply by bringing in the tbdex-kt dependency in the build.

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

@chrisgiglio Let's huddle live in 20min?

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

For 2) Yes - you can and probably have to not write real executable tests and just do Shnip. I'm working hand in hand with @jiyoontbd to get this unblocked ASAP. @jiyoontbd Can we proceed with your plan to update tbdex-kt to web5-kt:0.10.0, cut a new release, and then we might get unblocked temporarily while we structurally fix dependencies and build?

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

2:45 Pacific, can meet you in #adhoc-huddle

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

@jiyoontbd Could be a great near-term fix to unblock the team, but without the upgrade couldn't test it - I got failures. 🙂 Excited for your PR. And yes even though it could be a great near-term salve, we still gotta address the issue of locking dependencies unfortunately. @jiyoontbd Got an ETA on that PR and a new release of tbdex-kt for us to test that approach? @jiyoontbd Here's some context why I say that "could be a short-term" salve and not a long-term solution: * web5-kt is tested with its dependency tree. Great. * tbdex-kt adds its own dependencies, including web5-kt. It runs tbdex tests. * Now the Web5 stuff was tested under a different dependency tree than may be exported by tbDEX. * So a consumer, like the Dev Site, can come along and want to call the Web5 libraries exported via tbDEX. It can hit failures - because the dep tree it's consuming is different from the one that Web5 was tested against.

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

@jiyoontbd I'm hitting some Kotliney things I don't understand - could I pair with you today before 4 PST?

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

3:15 PST - thank you! @jiyoontbd Thank you again for that PR upgrading tbdex-kt to rely on web5-kt. Very helpful. Turns out the issue persists due to the same context I gave in bullets above. tbdex directly declares a version of jackson-core, for instance, which is different from the version the web5 code paths are relying on:

[INFO] Running website.tbd.developer.site.docs.web5.build.verifiablecredentials.JwtToVcTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.064 s <<< FAILURE! - in website.tbd.developer.site.docs.web5.build.verifiablecredentials.JwtToVcTest
[ERROR] getVerifiableCredentialFromJwt works  Time elapsed: 0.06 s  <<< ERROR!
java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/util/JacksonFeature
    at website.tbd.developer.site.docs.web5.build.verifiablecredentials.JwtToVcTest.getVerifiableCredentialFromJwt works(JwtToVcTest.kt:20)
Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.core.util.JacksonFeature
    at website.tbd.developer.site.docs.web5.build.verifiablecredentials.JwtToVcTest.getVerifiableCredentialFromJwt works(JwtToVcTest.kt:20)

[INFO] Running website.tbd.developer.site.docs.web5.build.verifiablecredentials.JwtToVcTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.064 s <<< FAILURE! - in website.tbd.developer.site.docs.web5.build.verifiablecredentials.JwtToVcTest
[ERROR] getVerifiableCredentialFromJwt works  Time elapsed: 0.06 s  <<< ERROR!
java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/util/JacksonFeature
    at website.tbd.developer.site.docs.web5.build.verifiablecredentials.JwtToVcTest.getVerifiableCredentialFromJwt works(JwtToVcTest.kt:20)
Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.core.util.JacksonFeature
    at website.tbd.developer.site.docs.web5.build.verifiablecredentials.JwtToVcTest.getVerifiableCredentialFromJwt works(JwtToVcTest.kt:20)

This is the proving point for why web5 and tbdex need explicit version alignment. Here's the full unresolved dependency tree just for jackson-core. If you look closely you'll see how web5 and tbdex are build against different versions and now consumers' builds have to do resolution to choose one (and choose wrong). Removing blocker for now; it may reappear. Details in new thread here

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

That’s not a great practice - tbDEX needs it. What should happen is that Web5 should lock the version and tbDEX, built atop Web5, should import those locked versions via a pom in import scope. Working with @jiyoontbd on these approaches.

Unknown User•5mo ago

Message Not Public

ALR•5mo ago

@moegrammer It could break. What I'm going to recommend is exporting the common dep tree from Web5 and from tbDEX so that consumers can bring that in, and built atop it. It won't bring in all versions, just those that come transitively through tbDEX and Web5. And it will also enforce versions for the consumers so everything plays nice. For instance if a consumer is doing JSON stuff and using jackson-core for that, by bringing in the tbDEX pom which enforces versions, the consumer will get the compatible one. That's what I'm working on as part of re-doing the builds for the Kotlin projects.

Gaming

Programming

**Blocker ** Adding `tbdex-kt` Support

Blocker Adding `tbdex-kt` Support