One in the reactor root drives every module, and the root POM is flattened so it publishes with the version resolved, so a release rewrites a single property.
Build-model only: no runtime or test changes. Validated with ./mvnw validate (Maven 3.9.11). Excludes the old release-caller/SDK CI commits.
One <revision> in the reactor root drives every module, and the root POM is flattened so it publishes with the version resolved, so a release rewrites a single property.
Build-model only: no runtime or test changes. Validated with ./mvnw validate (Maven 3.9.11). Excludes the old release-caller/SDK CI commits.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The reactor root (qbit-scripting-reactor, pom packaging, version ${revision}) is itself a module
the qrun publisher captures and enrolls; without the flatten plugin its consumer POM keeps the
unresolved ${revision} and the publisher rejects it. No source or dependency change.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The release pipeline rewrites <revision> only in the ROOT pom.xml (the pinned legacy calculate_version.sh) and nothing passes -Drevision
(java-verify runs plain `mvn verify` with MAVEN_ARGS only from caller inputs), but every module declared its own <revision>0.1.0-SNAPSHOT</revision>
and did not inherit the root. After an RC rewrite the root would say the RC while the modules still built as the SNAPSHOT, so capture
(target/<artifact>-<root version>.jar) would find no JAR and the publisher (one version per reactor) would reject the reactor.
Standard Maven CI-friendly inheritance: the root takes the modules' own former parent (qbit-build-parent 2.0.0, identical for all four
modules), every module's parent becomes the root (version ${revision}, relativePath ../pom.xml) and the per-module <revision> properties are
removed. Each module's inherited build configuration is unchanged (child -> root -> the same qbit-build-parent); modules still build on their
own through the relative parent. Metadata audit: the root declares Apache-2.0 and base declares it too (unchanged); rdbms, middleware and
github declared no license and inherited qbit-build-parent's AGPL-3.0, so they now state that same license explicitly to keep their published
metadata exactly as before (the repository LICENSE is Apache: whether those three should be Apache is an owner decision, not changed here).
All GAVs, module boundaries, flatten plugin, dependencies, tests and sources are unchanged.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Align every module to QQQ Core 4.1.0-RC.22 and replace the paused-checkpoint
status text with the current 1.0 status and operating limits.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
One in the reactor root drives every module, and the root POM is flattened so it publishes with the version resolved, so a release rewrites a single property.
Build-model only: no runtime or test changes. Validated with ./mvnw validate (Maven 3.9.11). Excludes the old release-caller/SDK CI commits.
Co-Authored-By: Claude Sonnet 5.5 noreply@anthropic.com
The reactor root (qbit-scripting-reactor, pom packaging, version ${revision}) is itself a module the qrun publisher captures and enrolls; without the flatten plugin its consumer POM keeps the unresolved ${revision} and the publisher rejects it. No source or dependency change. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>The release pipeline rewrites <revision> only in the ROOT pom.xml (the pinned legacy calculate_version.sh) and nothing passes -Drevision (java-verify runs plain `mvn verify` with MAVEN_ARGS only from caller inputs), but every module declared its own <revision>0.1.0-SNAPSHOT</revision> and did not inherit the root. After an RC rewrite the root would say the RC while the modules still built as the SNAPSHOT, so capture (target/<artifact>-<root version>.jar) would find no JAR and the publisher (one version per reactor) would reject the reactor. Standard Maven CI-friendly inheritance: the root takes the modules' own former parent (qbit-build-parent 2.0.0, identical for all four modules), every module's parent becomes the root (version ${revision}, relativePath ../pom.xml) and the per-module <revision> properties are removed. Each module's inherited build configuration is unchanged (child -> root -> the same qbit-build-parent); modules still build on their own through the relative parent. Metadata audit: the root declares Apache-2.0 and base declares it too (unchanged); rdbms, middleware and github declared no license and inherited qbit-build-parent's AGPL-3.0, so they now state that same license explicitly to keep their published metadata exactly as before (the repository LICENSE is Apache: whether those three should be Apache is an owner decision, not changed here). All GAVs, module boundaries, flatten plugin, dependencies, tests and sources are unchanged. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>87a04b363bto0df2fc81e4