|
| 1 | +# temporal-sdk-java |
| 2 | + |
| 3 | +Patch-based fork of [temporalio/sdk-java](https://github.com/temporalio/sdk-java) published to Maven Central under `com.pkware.temporal`. |
| 4 | + |
| 5 | +## What's different |
| 6 | + |
| 7 | +| Patch | Description | |
| 8 | +|-------|-------------| |
| 9 | +| 0001 | Replace Jackson with Moshi as default JSON converter | |
| 10 | +| 0002 | Remove GSON dependency | |
| 11 | +| 0003 | Replace grpc-netty-shaded with grpc-okhttp | |
| 12 | +| 0004 | Change groupId to `com.pkware.temporal` | |
| 13 | + |
| 14 | +## Maven coordinates |
| 15 | + |
| 16 | +```kotlin |
| 17 | +// build.gradle.kts |
| 18 | +implementation("com.pkware.temporal:temporal-sdk:1.35.0-pkware.1") |
| 19 | +testImplementation("com.pkware.temporal:temporal-testing:1.35.0-pkware.1") |
| 20 | +``` |
| 21 | + |
| 22 | +## Version scheme |
| 23 | + |
| 24 | +`{upstream}-pkware.{N}` — N starts at 1 for each new upstream version and increments for patch-only changes against the same upstream. |
| 25 | + |
| 26 | +## How it works |
| 27 | + |
| 28 | +No upstream source is committed. The repo contains only: |
| 29 | +- `patches/` — git format-patch files (the delta from upstream) |
| 30 | +- `scripts/` — shell scripts to apply/export patches |
| 31 | +- `overlay/` — files copied on top of the patched tree (publishing config, dependency versions) |
| 32 | +- `.github/workflows/` — CI automation |
| 33 | + |
| 34 | +`apply-patches.sh` clones upstream at a tag into `build/`, applies patches, and copies overlay files. |
| 35 | + |
| 36 | +## Local development |
| 37 | + |
| 38 | +```bash |
| 39 | +git clone https://github.com/pkware/temporal-sdk-java.git |
| 40 | +cd temporal-sdk-java |
| 41 | +./scripts/apply-patches.sh |
| 42 | + |
| 43 | +cd build |
| 44 | +./gradlew assemble |
| 45 | +./gradlew test |
| 46 | +``` |
| 47 | + |
| 48 | +Requires JDK 21. |
| 49 | + |
| 50 | +### Publishing locally |
| 51 | + |
| 52 | +```bash |
| 53 | +cd build |
| 54 | +./gradlew publishToMavenLocal -PoverrideVersion=1.35.0-pkware.1 |
| 55 | +``` |
| 56 | + |
| 57 | +Then add `mavenLocal()` to your consuming project's repositories block. |
| 58 | + |
| 59 | +## Dependency versions |
| 60 | + |
| 61 | +New dependencies introduced by patches (e.g. Moshi) have their versions in `overlay/gradle.properties`. This file is copied into `build/` by `apply-patches.sh` and is scannable by Renovate. |
| 62 | + |
| 63 | +## Modifying patches |
| 64 | + |
| 65 | +```bash |
| 66 | +./scripts/apply-patches.sh |
| 67 | + |
| 68 | +cd build |
| 69 | +# edit files... |
| 70 | +git add -A && git commit -m "Description of change" |
| 71 | + |
| 72 | +cd .. |
| 73 | +./scripts/create-patches.sh |
| 74 | + |
| 75 | +git add patches/ |
| 76 | +git commit -m "Update patches" |
| 77 | +``` |
| 78 | + |
| 79 | +## Resolving patch conflicts |
| 80 | + |
| 81 | +When `apply-patches.sh` fails because upstream changed a file that a patch touches, you need to resolve the conflict manually. |
| 82 | + |
| 83 | +```bash |
| 84 | +# 1. Start with a clean state |
| 85 | +rm -rf build |
| 86 | +./scripts/apply-patches.sh v1.36.0 |
| 87 | +# Script will fail and print which patch conflicted. |
| 88 | + |
| 89 | +# 2. Resolve conflicts in build/ |
| 90 | +cd build |
| 91 | + |
| 92 | +# Git leaves conflict markers in the affected files. Fix them: |
| 93 | +# - Open each conflicting file, resolve the markers (<<<< ==== >>>>) |
| 94 | +# - git add each resolved file |
| 95 | +git add <resolved-files> |
| 96 | +git am --continue |
| 97 | +# If additional patches also conflict, repeat: fix files, git add, git am --continue |
| 98 | + |
| 99 | +# 3. Verify the result compiles and tests pass |
| 100 | +./gradlew build |
| 101 | + |
| 102 | +# 4. Export the updated patches |
| 103 | +cd .. |
| 104 | +./scripts/create-patches.sh |
| 105 | + |
| 106 | +# 5. Update .upstream-version and commit |
| 107 | +echo "v1.36.0" > .upstream-version |
| 108 | +git add .upstream-version patches/ |
| 109 | +git commit -m "Resolve patch conflicts for v1.36.0" |
| 110 | +``` |
| 111 | + |
| 112 | +If a conflict is too complex to resolve (e.g. upstream rewrote an entire file), you can abort and start over: |
| 113 | + |
| 114 | +```bash |
| 115 | +cd build |
| 116 | +git am --abort |
| 117 | +# Now you're back at the upstream tag with no patches applied. |
| 118 | +# Make your changes fresh, commit them, and re-export. |
| 119 | +``` |
| 120 | + |
| 121 | +## Alerts and notifications |
| 122 | + |
| 123 | +The `sync.yml` workflow runs twice daily and automatically creates **GitHub Issues** when something goes wrong: |
| 124 | + |
| 125 | +- **"Patch conflict on upstream vX.Y.Z"** — patches didn't apply cleanly against the new upstream tag. Follow the [resolving patch conflicts](#resolving-patch-conflicts) steps above. |
| 126 | +- **"Test failure on upstream vX.Y.Z"** — patches applied but the build or tests failed. Usually means upstream changed behavior that our patches depend on. |
| 127 | + |
| 128 | +**To receive alerts**, subscribe to GitHub notifications for this repo: |
| 129 | +1. Go to the repo page on GitHub |
| 130 | +2. Click **Watch** → **All Activity** (or **Custom** → check **Issues**) |
| 131 | + |
| 132 | +Both issue types include a link to the failed CI run for debugging. |
| 133 | + |
| 134 | +## Publishing to Maven Central |
| 135 | + |
| 136 | +### Automatic (recommended) |
| 137 | + |
| 138 | +The `sync.yml` workflow handles publishing automatically when it detects a new upstream tag. It: |
| 139 | +1. Applies patches against the new tag |
| 140 | +2. Runs the full build and test suite |
| 141 | +3. Publishes all artifacts to Maven Central via Sonatype OSSRH |
| 142 | +4. Creates a GitHub Release |
| 143 | + |
| 144 | +No manual intervention needed — new upstream releases are published within 12 hours. |
| 145 | + |
| 146 | +### Manual |
| 147 | + |
| 148 | +Use the `manual-build.yml` workflow: |
| 149 | +1. Go to **Actions** → **Manual Build** |
| 150 | +2. Enter the upstream tag (e.g. `v1.35.0`) |
| 151 | +3. Check **Publish to Maven Central** |
| 152 | +4. Click **Run workflow** |
| 153 | + |
| 154 | +### Required secrets |
| 155 | + |
| 156 | +Both workflows need these repository secrets configured in GitHub: |
| 157 | + |
| 158 | +| Secret | Description | |
| 159 | +|--------|-------------| |
| 160 | +| `NEXUS_USERNAME` | Sonatype OSSRH username for Maven Central | |
| 161 | +| `NEXUS_PASSWORD` | Sonatype OSSRH password | |
| 162 | +| `SIGNING_KEY` | ASCII-armored GPG private key for artifact signing | |
| 163 | +| `SIGNING_KEY_ID` | GPG key ID (short or long form) | |
| 164 | +| `SIGNING_PASSWORD` | Passphrase for the GPG key | |
| 165 | + |
| 166 | +Without these secrets, the build/test steps still run, but publishing is skipped. |
| 167 | + |
| 168 | +### First-time setup |
| 169 | + |
| 170 | +If the PKWARE Sonatype account or GPG key doesn't exist yet: |
| 171 | +1. Register a Sonatype OSSRH account and claim the `com.pkware.temporal` namespace (or verify it's already claimed under the `com.pkware` group) |
| 172 | +2. Generate a GPG key pair: `gpg --gen-key` |
| 173 | +3. Export the private key: `gpg --armor --export-secret-keys <key-id>` |
| 174 | +4. Publish the public key to a keyserver: `gpg --keyserver keyserver.ubuntu.com --send-keys <key-id>` |
| 175 | +5. Add all four secrets to the GitHub repo settings |
| 176 | + |
| 177 | +## License |
| 178 | + |
| 179 | +Apache License 2.0 — same as upstream Temporal SDK. |
0 commit comments