Skip to content

chore: Migrate java-server-sdk-dynamodb-store to java-core - #241

Open
kinyoklion wants to merge 1 commit into
mainfrom
rlamb/dynamodb-store-java-core
Open

kinyoklion wants to merge 1 commit into
mainfrom
rlamb/dynamodb-store-java-core

Conversation

@kinyoklion

@kinyoklion kinyoklion commented Oct 26, 2026 •

Copy link
Copy Markdown
Member

Moves launchdarkly/java-server-sdk-dynamodb into lib/java-server-sdk-dynamodb-store and releases it with release-please. It follows the redis-store migration (#45) and the publishing changes made to that package since then (#48, #82, #153), so the DynamoDB package uses the same tooling as the rest of the repo.

Requirements

  • I have added test coverage for new or changed functionality
  • I have followed the repository's pull request submission guidelines
  • I have validated my changes against all supported platform versions

The library code and tests are unchanged. This PR's CI covers the platform matrix: Linux on Java 8/11/17/19 and Windows on Java 11/17.

Describe the solution you've provided

Package contents (lib/java-server-sdk-dynamodb-store/)

  • Sources, tests, checkstyle.xml, settings.gradle, CHANGELOG.md and the Gradle 7.6 wrapper are byte-for-byte copies of java-server-sdk-dynamodb@main. The wrapper is also identical to redis-store's.
  • .gitignore is the same as redis-store's.

Build changes (build.gradle, gradle.properties). The old repo could no longer publish.

  • Replaced de.marcphilipp.nexus-publish 0.4.0 and io.codearte.nexus-staging 0.30.0 with io.github.gradle-nexus.publish-plugin 1.3.0, and removed the nexusStaging block. publish.sh calls publishToSonatype closeAndReleaseSonatypeStagingRepository, and only the gradle-nexus plugin provides those tasks.
  • nexusPublishing now targets the Central Portal OSSRH staging API (ossrh-staging-api.central.sonatype.com) and the Central snapshots repo, the same as redis-store and otel. Credentials come from -PsonatypeUsername/-PsonatypePassword as with the other packages, so the ossrhUsername/ossrhPassword properties are gone.
  • Removed the oss.sonatype.org resolution repository. That host is retired and now redirects to a Maven Central path that doesn't exist. Redis-store still lists it and could drop it in a follow-up.
  • The POM url and scm now point at java-core.
  • Added #x-release-please-start-version markers around version in gradle.properties.

Repo wiring

  • release-please-config.json and .release-please-manifest.json: added lib/java-server-sdk-dynamodb-store with package name launchdarkly-java-server-sdk-dynamodb-store, starting from the last published version, 5.0.0. Tags will look like launchdarkly-java-server-sdk-dynamodb-store-5.0.1.
  • release-please.yml: added a package-server-sdk-dynamodb-store-released output and a release-server-sdk-dynamodb-store job, a copy of the redis-store job.
  • manual-publish.yml and manual-publish-docs.yml: added the package to the workspace choices.
  • .github/actions/ci/action.yml: starts amazon/dynamodb-local on port 8000 when the workspace is this package, like the Redis step.
  • New java-server-sdk-dynamodb-store.yml workflow:
    • Linux, Java 8/11/17/19, through the shared CI action.
    • Windows, Java 11/17, using the DynamoDB Local jar setup from the old repo's CI. It's laid out like the redis-store Windows job, except the Run Tests step runs on steps.build.outcome. The redis job keys that step on inputs.run_tests, which is always empty in a push/PR workflow, so that step never runs. build still runs the tests either way.
  • Root README.md: added a row and link references under "Other Packages".
  • Issue templates: added package-dynamodb-store--bug_report.md and package-dynamodb-store--feature_request.md.

Not carried over, because java-core already covers them or doesn't use them: .ldrelease/config.yml, the old CI action and workflow, stale.yml, dependabot.yml, gradle.properties.example, CODEOWNERS, LICENSE, SECURITY.md and CONTRIBUTING.md.

Release behavior

The commit override below makes release-please open a 5.0.1 release PR for this package after the merge. The only change to the published artifact is the POM metadata, the same kind of change as redis-store 3.1.1 (#153). That first release exercises the new pipeline end to end: Central Portal publish, signing, and docs to launchdarkly.github.io/java-core/lib/java-server-sdk-dynamodb-store/. To merge without releasing, delete the fix: line.

BEGIN_COMMIT_OVERRIDE
chore: Migrate java-server-sdk-dynamodb-store to java-core
fix: Update Maven POM URLs to java-core
END_COMMIT_OVERRIDE

Validation done locally (Temurin 8 container next to an amazon/dynamodb-local container)

  • gradlew dependencies, build (which includes checkstyleMain/checkstyleTest), jar and javadoc all succeed. 27 tests pass, 0 fail.
  • gradlew tasks --all lists publishToSonatype and closeAndReleaseSonatypeStagingRepository.
  • publishToMavenLocal produces the jar, sources, javadoc, .module and a POM with java-core url/scm.
  • All changed workflow and action YAML parses.

Before merging

  • Create the package: java-server-sdk-dynamodb-store label in java-core. The new issue templates and the README issues link use it.

After the first release from java-core

  • Confirm 5.0.1 is on Maven Central and the docs are on GitHub Pages.
  • Update the old repo's README to point at java-core, then archive launchdarkly/java-server-sdk-dynamodb, as was done for java-server-sdk-redis. Its maintenance branches (2.x, 3.x, 4.x, aws-v1) aren't migrated. It has no open issues or PRs.
  • Check docs.launchdarkly.com's DynamoDB page for links to the old repo or API docs.

Describe alternatives you've considered

  • Gradle 9 (old repo PR chore: Remove unused publishing dependency. #38): left out so the package matches redis-store and the rest of the repo on 7.6. Upgrading the Gradle wrapper can be done in a follow-up for the whole repo.
  • Keeping git history: the earlier migrations copied files and java-core squash-merges, so this PR does the same.

Additional context

Follow-ups this PR deliberately doesn't change, so the move stays behavior-neutral:

  • The software.amazon.awssdk:dynamodb API dependency is still pinned at 2.10.32 (2019). Applications get that version transitively unless they declare their own.
  • The minimum SDK version is still 6.0.0, where redis-store uses 6.3.0.
  • The old repo had Dependabot with a 7-day cooldown, but java-core has no Dependabot config.

Opened from termag


Note

Overview
Moves launchdarkly-java-server-sdk-dynamodb-store from the standalone java-server-sdk-dynamodb repo into lib/java-server-sdk-dynamodb-store, matching the redis-store monorepo pattern. Runtime library and tests are carried over as-is; the meaningful product change is repo and release plumbing, not new DynamoDB behavior.

Build and publish: build.gradle switches to io.github.gradle-nexus.publish-plugin and Sonatype Central Portal staging URLs, drops legacy OSSRH config, and points Maven POM url/scm at java-core. gradle.properties gets release-please version markers (starting at 5.0.0).

Automation: Registers the package in release-please-config.json, .release-please-manifest.json, manual-publish.yml, manual-publish-docs.yml, and adds a release-server-sdk-dynamodb-store job in release-please.yml. Shared CI starts DynamoDB Local (Docker on Linux) when building this workspace; a dedicated workflow runs Linux (Java 8/11/17/19) and Windows (11/17) builds.

Docs and triage: Root README lists the package; new GitHub issue templates use the package: java-server-sdk-dynamodb-store label.

Reviewed by Cursor Bugbot for commit c6a8f9e. Bugbot is set up for automated code reviews on this repo. Configure here.

Move launchdarkly/java-server-sdk-dynamodb into lib/java-server-sdk-dynamodb-store
and release it with release-please, following the redis-store migration.

- Copy the sources, tests, Gradle wrapper (7.6), checkstyle config and
  CHANGELOG unchanged.
- Replace the de.marcphilipp.nexus-publish and io.codearte.nexus-staging
  plugins with io.github.gradle-nexus.publish-plugin 1.3.0 and publish through
  the Central Portal OSSRH staging API, as the other packages do.
- Drop the retired oss.sonatype.org repository and the unused ossrh
  credential properties.
- Point the POM url and scm at java-core.
- Add the package to release-please, the release workflow, the manual publish
  workflows, the shared CI action (DynamoDB Local on Linux) and a package
  workflow (Linux Java 8/11/17/19, Windows Java 11/17).
- Add the package to the root README and add issue templates.

Generated-by: termag
@kinyoklion

Copy link
Copy Markdown
Member Author

There were a number of dependabot items against the old location, and it looks like it isn't ready to easily be released. So moving it here should make it releasable when we need it, and we can archive the old repo.

@kinyoklion
kinyoklion marked this pull request as ready for review October 26, 2026 22:39
@kinyoklion
kinyoklion requested a review from a team as a code owner October 26, 2026 22:39

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit c6a8f9e. Configure here.

mkdir dynamo
Expand-Archive -Path dynamo.zip -DestinationPath dynamo
cd dynamo
Start-Process -FilePath "java" -ArgumentList "-D`"java.library.path=./DynamoDBLocal_lib`"","-jar","DynamoDBLocal.jar"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Windows Java 11 cannot run DynamoDB

Medium Severity

The Windows job downloads dynamodb_local_latest.zip and starts it with the matrix JDK, which includes Java 11. Current DynamoDB Local requires Java 17 or newer, so that job never gets a process listening on port 8000 and the integration tests fail. Start-Process also does not fail the step when the JVM exits immediately, so the setup step stays green.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit c6a8f9e. Configure here.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant