Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor Kotlin Build #271

Open
ALRubinger opened this issue Jul 26, 2024 · 6 comments
Open

Refactor Kotlin Build #271

ALRubinger opened this issue Jul 26, 2024 · 6 comments
Assignees

Comments

@ALRubinger
Copy link
Contributor

Handle all build features of web5-kt:

  • Docs
  • Code Coverage
  • Signing (GPG)
  • Publishing (Maven Central and Artifactory)

Also establish clean dependencyManagement.

@ALRubinger
Copy link
Contributor Author

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.

@ALRubinger
Copy link
Contributor Author

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.

@ALRubinger
Copy link
Contributor Author

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.

@ALRubinger
Copy link
Contributor Author

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.

ALRubinger added a commit that referenced this issue Jul 27, 2024
* Starting point
* Issue comments show status
* Builds
* Tests
* Builds Javadoc in target/dokkaJavadocJar
* Does not yet have release or pipelines
@ALRubinger
Copy link
Contributor Author

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.

@KendallWeihe
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

2 participants