Open ALRubinger opened 1 month ago
We likely cannot rely on maven-release-plugin
to cut the release as it tags, bumps versions, etc to SCM from the root, and the Kotlin impl here is a subdirectory of the repo and is not authoritative from the root. This is nonstandard practice for a system that relies on convention and will require specialized build handling unlike we have now in web5-kt
.
By moving away from the multimodule build, we lose the ability to have a parent pom.xml
of type pom
, therefore making it so we cannot export dependency versions in a BOM POM. So we either have to make this a multimodule build or forgo having BOM POMs and lose the enforcement of versions we had before in web5-kt
, making dependency management brittle.
Detekt is failing w/ the new codebase so I'm commenting it out and it won't run as part of build lifecycle unless we address the underlying code stuff w/ team - up to @KendallWeihe and @nitro-neal to advise if this is desired.
If this is all in one module, no multi-module build, where do we put the new AwsKeyManager
implementation? In web5-kt
we put this in its own module because it drags a boatload of dependencies with it that we didn't want in the main distribution.
Similar question would apply for an AndroidKeyManager
implementation, which would probably be an extension repo rather than another module because Androidey things want a Gradle build.
Pushed some work on this build in linked commit above. Will switch now to tbdex-rs
as the web5-rs
Maven binaries are not a transitive dependency of tbdex-rs/Kotlin
, and that's what we need to deliver more near-term.
Good questions regarding AwsKeyManager
and AndroidKeyManager
causing bloat, but a problem for a later date.
Same comment as here with regards to going ahead and setting up multi-module-but-with-only-one-module if it makes your life easier in the near term
Handle all build features of
web5-kt
:Also establish clean
dependencyManagement
.