Fix Maven Central publishing and sync build with mailersend-java

[robgordon89]

Why?

The publish workflow has never run in this repo. It still uses checkout/setup-java v3 and old Maven plugins, so 0.0.4 has never been released. mailersend-java's publishing broke when it moved to setup-java v6, and mailersend/mailersend-java#141 fixed it by bumping maven-gpg-plugin to 3.2.8. This PR copies that working setup so that publishing a GitHub release puts the version on Maven Central with no manual steps.

Changes

1. publish.yaml is now mailersend-java's workflow: checkout v7 and setup-java v6 pinned by SHA, JDK 11 instead of 17, and no -P release (that profile doesn't exist). It adds one step, which fails a release whose tag (with or without a leading v) doesn't match the pom version.
2. pom.xml plugins are all on mailersend-java's versions. The signing fix is maven-gpg-plugin 1.6 → 3.2.8: setup-java v6 expects the plugin to read MAVEN_GPG_PASSPHRASE from the environment, which 3.2.x does and 1.6 doesn't.
3. pom.xml dependencies: gson 2.8.7 → 2.13.2, commons-io 2.7 → 2.21.0, junit 5.7.0 → 5.14.3, plus junit-platform-launcher, as in mailersend-java.
4. test.yml is copied from mailersend-java and runs mvn test on JDK 11, 17 and 21 for pushes and PRs to main. The tests replay recorded fixtures, so the job needs no secrets.
5. renovate.json uses the org :base preset, same as mailersend-java. The :app preset from onboarding PR chore: Configure Renovate #15 turns off the maven manager, so it would never bump the pom.

Risks

• testFailureIgnore stays on, as in mailersend-java, so the Build check passes even when tests fail. The Tests run: line in each job log is the only place a regression from the gson upgrade will show.
• Javadoc now builds on JDK 11 with plugin 3.12.0 (it was JDK 17 with 3.0.1). The PR check doesn't build javadoc, so the first build is at release. If it fails there, the build stops before anything is uploaded.
• gson and commons-io are runtime dependencies, so SDK users get the newer versions through this dependency.
• If the GPG signing key is new, its public key has to be on a keyserver Central checks (keyserver.ubuntu.com, keys.openpgp.org), or Central rejects the bundle.

Performance impact

None. Only the build and CI config change; the SDK source is untouched.

Security impact

Actions are pinned by commit SHA. The gson and commons-io bumps fix CVE-2022-25647 and CVE-2024-47554. Nothing changes in how the SDK handles credentials or requests.

How to QA

1. On this PR, open each Java 11/17/21 Test job, then the Run test suite step. Expect Tests run: 45, Failures: 0, Errors: 0. The check passes regardless, so read this line.
2. After merging, publish a GitHub release with tag v0.0.4 on main. The Maven Publish run should pass the tag check, sign with gpg:3.2.8 and finish with the deployment published.
3. Check that https://repo1.maven.org/maven2/com/mailerlite/mailerlite-java/maven-metadata.xml lists 0.0.4.

SDK behaviour doesn't need QA, since no source files changed.

How to release

Merge, then publish a GitHub release tagged v0.0.4 against main. Don't use "Run workflow" on Maven Publish as a dry run: a manual run skips the tag check and publishes whatever version the pom has on main.

Rollback strategy

• Migrations: none.
• Data changes: none.
• External dependencies: Maven Central releases can't be changed or deleted. A bad 0.0.4 can only be replaced by releasing 0.0.5.
• Config: revert this PR to restore the previous workflows and pom.

Screenshots, recordings

N/A

I used AI to generate parts of this PR

Yes

🤖 Generated with Claude Code