Description

buildSrc has a major drawback of invalidating entire project's cache after a chance in the buildSrc itself. This is a probably not a big issue for the project of this size, but a way to fix this is to implement plugin as a standalone, composite build, which also happens to be a more idiomatic way of implementing plugins.

Notes to the reviewers

These are the rough steps that I took for converting the plugin:

1. . Create new standalone plugins Gradle module for the plugin
2. Create two new UniFfiJvmPlugin and UniFfiAndroidPlugin Gradle plugin classes, copy-and-pasting existing script plugin implementations
3. Register two new plugins using the same IDs as convention plugins: org.bitcoindevkit.plugins.generate-jvm-bindings and org.bitcoindevkit.plugins.generate-android-bindings
4. Delete buildSrc

All Submissions:

• [x] I've signed all my commits
• [x] I followed the contribution guidelines

Problem

It seems that sources and javadocs for bdk-android are not being generated and published to maven: https://repo1.maven.org/maven2/org/bitcoindevkit/bdk-android/0.4.0.

Description

When using bdk-android as a library in your project it's not currently possible to look up source code and documentation of bdk-android because sources and javadocs are not being generated and published.

With AGP 7.1.0 publishing Android sources and javadocs is very simple, we can use that https://developer.android.com/studio/releases/gradle-plugin#build-variant-publishing.

Alternatives

No response

Description

Update bdk-ffi to https://github.com/bitcoindevkit/bdk-ffi/pull/123 and add new TxBuilder tests.

Notes to the reviewers

I also fixed tests to use network and addresses for TESTNET to match BlockchainConfig.

The tests must be a bit hacky until we have a way to use REGTEST for our Kotlin tests.

Checklists

All Submissions:

• [x] I've signed all my commits
• [x] I followed the contribution guidelines
• [x] I ran cargo fmt and cargo clippy before committing

New Features:

• [x] I've added tests for the new feature
• [x] I've added docs for the new feature
• [ ] I've updated CHANGELOG.md

Description

This PR adds a directory that contains the required files to build the API docs for bdk-android and bdk-jvm. The docs need to be updated and published once a release.

Notes to the reviewers

After getting comments on how specific-language API docs are useful in dev calls, I add these (albeit in a temporary fashion). We don't know how long it will be before the ability to use inline documentation is added to uniffi-rs, and so for the foreseeable future this is a good solution that will allow us to publish Kotlin API docs that work well and look good, and keep track of them in the same repository as the libraries themselves. I fully expect to remove this directory once the new workflows are in.

All Submissions:

• [x] I've signed all my commits
• [x] I followed the contribution guidelines

Description

This PR adds two internal Gradle plugins which live in the buildSrc directory. The purpose of the plugins is to replace the build.sh script by a more idiomatic and customizable workflow using Gradle tasks.

Notes to the reviewers

By default the :android:buildAndroidLib task will build all versions of bdk-android, which currently are the arm64-v8a (for mobile devices) and the x86_64 (for emulators).

Users can opt out of a particular build if they'd like by excluding the task like so:

./gradlew :android:buildAndroidLib --exclude-task buildAndroidX86_64Binary

This PR is open as a discussion piece on the direction I am taking for implementing the next iteration of our build logic.

To test the plugins, first see that the tasks have been added using ./gradlew tasks, which should add the Bitcoindevkit group to the list of Gradle tasks:

Then run either tasks to build the given library:

./gradlew :jvm:buildJvmLib
./gradlew :android:buildAndroidLib

All Submissions:

• [x] I've signed all my commits

New Features:

• [ ] I've added tests for the new feature
• [x] I've added docs for the new feature

The following block is no longer necessary as of Kotlin 1.5 (we're currently using 1.6.10):

allprojects {
    tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().configureEach {
        kotlinOptions.freeCompilerArgs += "-opt-in=kotlin.ExperimentalUnsignedTypes"
    }
}

See uniffi-rs docs here and related merged PR here for more info.

I can't assign myself but @notmandatory feel free to assign me this one.

Description

Migrating the Gradle build scripts to Kotlin DSL.

Fixes #9

Notes to the reviewers

I have not tested the publishing workflow.

All Submissions:

• [x] I've signed all my commits

Description

ANDROID_HOME, ANDROID_SDK_HOME, and ANDROID_NDK_HOME are not used by the Android platform and SDK tools so these are considered deprecated/invalid.

Google recommends using ANDROID_SDK_ROOT and ANDROID_NDK_ROOT instead:

• https://groups.google.com/g/android-ndk/c/qZjhOaynHXc/m/2ux2ZZdxy2MJ
• https://developer.android.com/studio/command-line/variables

All Submissions:

• [x] I've signed all my commits
• [x] I followed the contribution guidelines
• [x] I ran cargo fmt and cargo clippy before committing

I think forcing contributors to set up gpg signatures to simply test/deploy the library locally might be an unnecessary friction we could easily remove.

Problem

It would be great to be able to generate library docs.

Description

I might have a working solution on this branch of my repo.

The workflow is as follows:

1. create a fresh bindings file
2. apply the patch docs.patch using patch jvm/src/main/kotlin/org/bitcoindevkit/bdk.kt docs.patch
3. generate the website using ./gradlew :jvm:dokkaHtml

The main question I have and the reason I have not put too much time in trying to port over all of the docs and polishing the current branch is that the patch does not seem to apply that easily, and I don't know to which extent the addition of a new API changes the bindings file. If the changes are extensive, I assume the patch will not work, and I'm still looking at a good way to fix that (like some interactive way using a GUI maybe), because at the moment when the patch fails it just... fails miserably but doesn't tell you much about why and where.

See the current state of the docs here: bdk-android: https://thunderbiscuit.github.io/bdk-android-api-docs/ bdk-jvm: https://thunderbiscuit.github.io/bdk-jvm-api-docs/

Honestly they look pretty good! The question is whether changes will always completely break them or if the process can be streamlined well.

This PR is a cherry-pick of 6c904cd26e6d994ab7e529856f580541d97a7a89 and 579c7cb07e2dc61a229d5f34ff775d680299d49b that adds the group and version properties to the root build.gradle.kts file. These properties are required for the nexus publish-plugin to work properly.

It also makes the default publishing workflow publish entirely instead of only to the staging repo.

Related to this PR is issue bitcoindevkit/bdk-ffi#234.