chore(release): prepare 0.2.0 (QQQ 4.1, Forge sync fix) #29

Merged

james.maes merged 3 commits from chore/release-0.2.0-20261106 into main 2026-11-06 15:32:35 +00:00

Conversation 0 Commits 3 Files Changed 7

+145 -18

james.maes commented 2026-11-06 14:46:28 +00:00

Owner

Copy link

Copy source

Summary

Prepares (does not cut) release 0.2.0 of com.kingsrook.qbits:qbit-geo-data so GG Forge can replace its development pin 0.1.0-forge.6ac6a0366c34-sync1 with a published artifact.

• pom.xml: <revision> 0.2.0-SNAPSHOT -> 0.2.0. main already started the 0.2.0 line (6337bfe) because the QQQ dependency moved from 0.35.0 to 4.1 (qqq-bom-pom 4.1.0-RC.21); that is a minor, not a patch, so 0.1.1 is not appropriate. The root <parent> version 1.5.1 is com.kingsrook:qbit-build-parent, unrelated to this project's version.
• GeoDataQBitProducer.VERSION and its test: 0.1.0 -> 0.2.0 (the constant had drifted from the pom).
• Port of the Forge geo-data-sync.patch sync-step fix (GeoDataSyncStep). Only the entity/producer half of that patch had landed on main (b5787bb); GeoDataSyncStep.java was still the 0.1.0 version, which reports success after persisting 250 countries and zero states/cities because the countryAlpha2/stateCode natural keys do not exist in the schema. Without this hunk, 0.2.0 would not be a functional drop-in for the Forge pin. The hunk is byte-for-byte the Forge-qualified change except that the inline java.math. qualifications became imports and the class Javadoc now states the real natural keys.
• flatten-maven-plugin 1.7.3 (resolveCiFriendliesOnly) in the root POM, .flattened-pom.xml ignored. The root POM keeps its version in the CI-friendly ${revision} property and the shared workflow deploys with a plain mvn deploy, so the published module POM carried <parent><version>${revision}</version>. Verified with a throwaway consumer against an isolated repository (Maven 3.9.11): without the plugin, Could not find artifact com.kingsrook.qbits:qbit-geo-data-parent:pom:${revision}; with it, the installed POM declares parent 0.2.0 and com.kingsrook.qbits:qbit-geo-data:jar:0.2.0 resolves through the full parent chain. (The retired CircleCI orb path published resolved POMs, 68e85e6; the ci-workflows path does not.) This is also why Forge needed its hand-written geo-data-consumer.pom.
• CHANGELOG.md: 0.2.0 entry; the stale "Unreleased" bullets (all shipped in 0.1.0) moved under [0.1.0] - 2025-12-28.
• README.md: correct artifactId (qbit-geo-data, not qbit-geo-data-core), version 0.2.0, Java 21 / QQQ 4.1 requirement, Gitea registry coordinates.

Verification

mvn -B -T4 verify on Java 21.0.12.1 (Temurin) with Maven 3.9.11 (the version CI's maven:3.9.11-eclipse-temurin-21 image uses): BUILD SUCCESS, reactor 0.2.0, core tests 29 run / 0 failures / 0 errors / 0 skipped, artifact qbit-geo-data-0.2.0.jar. Note for local builders: Maven 3.10.0 aborts before compiling with Invalid Artifact Requests: com.kingsrook:qbit-build-parent:pom:${revision} because the parent POM published to Central (1.5.1, and 2.0.0 alike) is unflattened; this repo has no Maven wrapper, so use a 3.9.x distribution. No Checkstyle plugin exists in this repo or its parent chain (qbit-build-parent 1.5.1 only configures compiler/source/javadoc/gpg), so verify is the full local gate; the Gitea build workflow runs the same mvn -T4 verify on push.

Not done here (post-merge)

No tag, release or publish. On this repo a push to main only verifies; the v0.2.0 tag publishes through KofTwentyTwo/ci-workflows maven.yaml. Note the branch is deliberately not named release/*: that prefix is the RC lane in the shared workflow and would publish 0.2.0-RC.1 and tag it on push.

🤖 Generated with Claude Code

## Summary Prepares (does not cut) release **0.2.0** of `com.kingsrook.qbits:qbit-geo-data` so GG Forge can replace its development pin `0.1.0-forge.6ac6a0366c34-sync1` with a published artifact. - `pom.xml`: `<revision>` 0.2.0-SNAPSHOT -> **0.2.0**. `main` already started the 0.2.0 line (6337bfe) because the QQQ dependency moved from 0.35.0 to 4.1 (`qqq-bom-pom` 4.1.0-RC.21); that is a minor, not a patch, so 0.1.1 is not appropriate. The root `<parent>` version 1.5.1 is `com.kingsrook:qbit-build-parent`, unrelated to this project's version. - `GeoDataQBitProducer.VERSION` and its test: 0.1.0 -> 0.2.0 (the constant had drifted from the pom). - **Port of the Forge `geo-data-sync.patch` sync-step fix** (`GeoDataSyncStep`). Only the entity/producer half of that patch had landed on `main` (b5787bb); `GeoDataSyncStep.java` was still the 0.1.0 version, which reports success after persisting 250 countries and zero states/cities because the `countryAlpha2`/`stateCode` natural keys do not exist in the schema. Without this hunk, 0.2.0 would not be a functional drop-in for the Forge pin. The hunk is byte-for-byte the Forge-qualified change except that the inline `java.math.` qualifications became imports and the class Javadoc now states the real natural keys. - **`flatten-maven-plugin` 1.7.3 (`resolveCiFriendliesOnly`)** in the root POM, `.flattened-pom.xml` ignored. The root POM keeps its version in the CI-friendly `${revision}` property and the shared workflow deploys with a plain `mvn deploy`, so the published module POM carried `<parent><version>${revision}</version>`. Verified with a throwaway consumer against an isolated repository (Maven 3.9.11): **without** the plugin, `Could not find artifact com.kingsrook.qbits:qbit-geo-data-parent:pom:${revision}`; **with** it, the installed POM declares parent `0.2.0` and `com.kingsrook.qbits:qbit-geo-data:jar:0.2.0` resolves through the full parent chain. (The retired CircleCI orb path published resolved POMs, 68e85e6; the ci-workflows path does not.) This is also why Forge needed its hand-written `geo-data-consumer.pom`. - `CHANGELOG.md`: 0.2.0 entry; the stale "Unreleased" bullets (all shipped in 0.1.0) moved under `[0.1.0] - 2025-12-28`. - `README.md`: correct artifactId (`qbit-geo-data`, not `qbit-geo-data-core`), version 0.2.0, Java 21 / QQQ 4.1 requirement, Gitea registry coordinates. ## Verification `mvn -B -T4 verify` on Java 21.0.12.1 (Temurin) with **Maven 3.9.11** (the version CI's `maven:3.9.11-eclipse-temurin-21` image uses): `BUILD SUCCESS`, reactor `0.2.0`, core tests 29 run / 0 failures / 0 errors / 0 skipped, artifact `qbit-geo-data-0.2.0.jar`. Note for local builders: Maven 3.10.0 aborts before compiling with `Invalid Artifact Requests: com.kingsrook:qbit-build-parent:pom:${revision}` because the parent POM published to Central (1.5.1, and 2.0.0 alike) is unflattened; this repo has no Maven wrapper, so use a 3.9.x distribution. No Checkstyle plugin exists in this repo or its parent chain (`qbit-build-parent` 1.5.1 only configures compiler/source/javadoc/gpg), so `verify` is the full local gate; the Gitea `build` workflow runs the same `mvn -T4 verify` on push. ## Not done here (post-merge) No tag, release or publish. On this repo a push to `main` only verifies; the `v0.2.0` tag publishes through `KofTwentyTwo/ci-workflows` `maven.yaml`. Note the branch is deliberately **not** named `release/*`: that prefix is the RC lane in the shared workflow and would publish `0.2.0-RC.1` and tag it on push. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james.maes added 2 commits 2026-11-06 14:46:28 +00:00

fix(sync): resolve country and state foreign keys and fail on rejected rows ... 2fd63e734b

Port the sync-step half of GG Forge's qualified geo-data-sync.patch (its
entity/producer half landed in b5787bb). The 0.1.0 step matched states on
countryAlpha2 + code and cities on countryAlpha2 + stateCode + name, columns
that do not exist in the schema, so it reported success after persisting 250
countries and zero states or cities.

Resolve the bundled source codes to the persisted countryId and
stateProvinceId before matching; match cities on stateProvinceId, name,
latitude and longitude at the schema's seven-decimal precision; compare
numbers by BigDecimal value so a second run is a no-op; reactivate an
inactive row whose source entry returns; and check insert/update results so
a row the backend rejects fails the sync with a QException.

Same change as the Forge pin 0.1.0-forge.6ac6a0366c34-sync1, with the inline
java.math qualifications turned into imports and the class Javadoc updated.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>

chore(release): prepare 0.2.0 ... 401e7ca471

Set the revision to 0.2.0: main already started the 0.2.0 line (6337bfe)
because the QQQ dependency moved from 0.35.0 to 4.1.0-RC.21, a minor
change, not a patch. Align GeoDataQBitProducer.VERSION and its test with
the pom. Add the 0.2.0 changelog entry, move the already-shipped 0.1.0
bullets out of Unreleased, and correct the README coordinates
(artifactId qbit-geo-data, version 0.2.0, Gitea registry, Java 21 / QQQ 4.1).

No tag, release or publish: a push to main only verifies; the v0.2.0 tag
publishes through the shared ci-workflows Maven workflow.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>

james.maes added 1 commit 2026-11-06 14:51:27 +00:00

build(pom): flatten the CI-friendly revision in published POMs ... b50515a8e8

The root pom keeps its version in the CI-friendly ${revision} property and
the shared ci-workflows Maven workflow deploys with a plain mvn deploy, so
the installed and deployed module POMs carried an unresolved
<parent><version>${revision}</version> that a consuming build cannot resolve
(the retired CircleCI orb path published resolved POMs, 68e85e6). Add
flatten-maven-plugin 1.7.3 in resolveCiFriendliesOnly mode so the published
POMs carry the literal version; ignore the generated .flattened-pom.xml.

Verified with Maven 3.9.11: clean verify passes (29 tests), the installed
qbit-geo-data-0.2.0.pom declares parent version 0.2.0, and a throwaway
consumer resolves com.kingsrook.qbits:qbit-geo-data:0.2.0 through the full
parent chain.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>

james.maes merged commit 1da0afa587 into main 2026-11-06 15:32:35 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

bug

Something isn't working

dependencies

documentation

Improvements or additions to documentation

duplicate

This issue or pull request already exists

enhancement

New feature or request

good first issue

Good for newcomers

help wanted

Extra attention is needed

invalid

This doesn't seem right

java

Pull requests that update java code

question

Further information is requested

secuurity

wontfix

This will not be worked on

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

forge-recovery (Forge Recovery) james.maes (James Maes)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qbit-geo-data#29