Publish prep

[mistermoe]

What's Changed

• explicitly set minimum compatible java version to java 17
• add jitpack config file to configure runner to use java 17
• remove redundant version declarations in packages
• fix message and resource digest computations
  • sha-256 hashing the canonicalized json was missing
• verify - default assertionMethods to an empty list if null

[mistermoe]

@jiyoontbd thoughts on making e2e file an integration test of http-client? we can do so by adding an integration-tests package to http-client/src. Otherwise we'll need to shuffle some stuff around in the build.gradle.kts files so that the e2e package isn't published.

[mistermoe]

@michaelneale is the current state of httpserver taking ktor.server for a test drive to see what it's capable of? if so, thoughts on moving your findings to a branch or issue? thinking about removing the module until there's some meat on the bones

[michaelneale]

Yep the server is just a placeholder - can move it

[michaelneale]

@mistermoe yeah after you merge (or part of this) could move it out, or just don't publish the server? #23 is the issue BTW. I opened up branch: https://github.com/TBD54566975/tbdex-kt/tree/impl-server-scaffold - which has the changes as they were, if you remove them from this branch, just open that issue with it linked to it for future reference if you like.

[KendallWeihe]

Should we add UnusedImports to our detekt config? @phoebe-lew any thoughts?

style:
  UnusedImports:
    active: false

[jiyoonie9]

@jiyoontbd thoughts on making e2e file an integration test of http-client? we can do so by adding an integration-tests package to http-client/src. Otherwise we'll need to shuffle some stuff around in the build.gradle.kts files so that the e2e package isn't published.

Totally good with me if you'd like to move the e2e.kt into httpclient in this PR :)

[jiyoonie9]

could also do emptyList() :)

[mistermoe]

oo good call!

[mistermoe]

done 802f4ce thanks @jiyoontbd !

[KendallWeihe]

Do we want to go ahead and bump to

implementation("com.github.TBD54566975:web5-kt:0.0.5-beta")

[mistermoe]

yep good call @KendallWeihe. on it

[mistermoe]

@KendallWeihe bumped. thoughts on surfacing web5-kt via api dependency instead of implementation? prevents people from having to include both as deps

[KendallWeihe]

@KendallWeihe bumped. thoughts on surfacing web5-kt via api dependency instead of implementation? prevents people from having to include both as deps

Yeah it's the same question we're puzzling over in tbdex-js with regards to the peer dependencies. I think it's sort of a six of one, half a dozen to the other. I do think I side with the peer dependency approach because of one particular reason, I outlined it in this comment.

I thought more about this and am fully bought in with this approach. The primary reason being Developer experience. Sure it's a slightly less good experience to have to install two packages. But, it makes the distinction between tbdex the transport agnostic protocol and the specific implementation over http much less ambiguous. Which is to say we're making it clear that tbdex isn't married to http.