One <revision> in the reactor root drives every module, the vendored OpenHTML module publishes at the family version, and its modification notice is updated.
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 qrun publisher declares one version per reactor and the capture step looks for
target/<artifact>-<root version>.jar, so the vendored OpenHTML module (own version
1.1.105-qqq-p1) could not be published with the family. Keep the GAV group and artifact
(com.kingsrook.thirdparty:openhtmltopdf-pdfbox), make its version the family ${revision}
(default 0.1.0-SNAPSHOT, like the other modules), flatten its consumer POM, and point
renderer at ${revision}. Java sources and renderer behaviour are unchanged.
The module keeps its explicit LGPL-2.1-or-later license and records upstream provenance
(tag 1.1.105, commit 54b31598, patch level p1, upstream project URL and scm) in properties,
url and scm; it does not inherit the Apache license of the reactor. The hash-pinned
complete-source archive is regenerated with the same module/pom.xml (inputs.sha256 updated;
module/pom.xml is again identical to the module pom) and build-openhtml.sh derives the
artifact names from the module revision. The reactor root is itself a pom-packaging module
the publisher checks, so it gets the flatten plugin (otherwise ${revision} stays unresolved).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
QQQ-MODIFICATIONS.txt (shipped in the jar's META-INF) still named the artifact 1.1.105-qqq-p1. The
module is now published at the QBit Document Generation family version, so the notice states that the
modified library is upstream 1.1.105 with QQQ patch level 1 (originally distributed as 1.1.105-qqq-p1)
and points at the openhtml.* POM properties. The LGPL modification statement is otherwise unchanged. The
hash-pinned complete-source archive carries the same file bytes and inputs.sha256 is updated.
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`), 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.
The root now inherits qbit-build-parent 2.1.1 (foundation's existing parent) and every module inherits the root with the per-module <revision> removed
(relativePath ../pom.xml, ../../pom.xml, ../../../pom.xml; remote-renderer transport and adapter keep inheriting remote-renderer-parent). GAVs, module list,
dependencies, sources and tests are unchanged. Audited with `help:effective-pom` (Maven 3.9.11, before/after for all 11 projects):
- licenses: root, foundation (Apache-2.0) unchanged; bridges/scripting previously inherited AGPL-3.0 from build-parent 2.0.0 and now states it explicitly (build
parent 2.0.0 -> 2.1.1 for this module); the vendored OpenHTML module keeps its explicit LGPL-2.1+ entry (a child's <licenses> replaces the parent's); the seven
modules that had no license (renderer, bridges/renderer, record-files, printing, remote-renderer parent/transport/adapter) now inherit the root's Apache-2.0,
matching the repository LICENSE.
- compiler: build-parent adds <source>21</source><target>21</target> to the compiler plugin; identical to the modules' maven.compiler.release 21; the Java 8
vendor module pins <source>8</source><target>8</target> explicitly next to maven.compiler.release 8 (testRelease 21 unchanged).
- dependency management: build-parent imports qqq-bom-pom 4.0.0 (jackson 2.21.5, qqq 4.0.0, ...) which the parentless modules never had. record-files and printing now
import qqq-bom-pom ${qqq.version} (as foundation and bridges/scripting already do), so their managed versions equal what qqq-backend-core RC.21 declares; renderer,
bridges/renderer and remote-renderer-parent import jackson-bom 2.22.4 so jackson-core/annotations stay aligned with their explicit jackson-databind 2.22.4.
- guardrails: build-parent 2.1.1 adds the qbit-guardrails test dependency, surefire dependenciesToScan and enforcer executions. foundation keeps them
(enforcer.skip false); the other modules keep the previous behavior (enforcer.skip true, dependenciesToScan reset); the extra test-scope qbit-guardrails
dependency and the snapshots-only central-portal-snapshots repository are inherited metadata.
- url/scm: the root states build-parent's url/scm so the modules' derived metadata stays the same.
The vendor's complete-source ZIP now ships parent/pom.xml (a copy of the reactor POM; module/pom.xml differs from the repository POM only in its relativePath,
../parent/pom.xml inside the archive), inputs.sha256 and the verify/build scripts follow, the README documents it, and renderer/Dockerfile copies the reactor POM from a named
BuildKit context. Not built or tested: model introspection only.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The shared Maven workflow reads the version with grep -m1 on the revision
element, so a comment mentioning the element made it parse prose as the
version and fail every publish run.
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, the vendored OpenHTML module publishes at the family version, and its modification notice is updated.
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 qrun publisher declares one version per reactor and the capture step looks for target/<artifact>-<root version>.jar, so the vendored OpenHTML module (own version 1.1.105-qqq-p1) could not be published with the family. Keep the GAV group and artifact (com.kingsrook.thirdparty:openhtmltopdf-pdfbox), make its version the family ${revision} (default 0.1.0-SNAPSHOT, like the other modules), flatten its consumer POM, and point renderer at ${revision}. Java sources and renderer behaviour are unchanged. The module keeps its explicit LGPL-2.1-or-later license and records upstream provenance (tag 1.1.105, commit 54b31598, patch level p1, upstream project URL and scm) in properties, url and scm; it does not inherit the Apache license of the reactor. The hash-pinned complete-source archive is regenerated with the same module/pom.xml (inputs.sha256 updated; module/pom.xml is again identical to the module pom) and build-openhtml.sh derives the artifact names from the module revision. The reactor root is itself a pom-packaging module the publisher checks, so it gets the flatten plugin (otherwise ${revision} stays unresolved). 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`), 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. The root now inherits qbit-build-parent 2.1.1 (foundation's existing parent) and every module inherits the root with the per-module <revision> removed (relativePath ../pom.xml, ../../pom.xml, ../../../pom.xml; remote-renderer transport and adapter keep inheriting remote-renderer-parent). GAVs, module list, dependencies, sources and tests are unchanged. Audited with `help:effective-pom` (Maven 3.9.11, before/after for all 11 projects): - licenses: root, foundation (Apache-2.0) unchanged; bridges/scripting previously inherited AGPL-3.0 from build-parent 2.0.0 and now states it explicitly (build parent 2.0.0 -> 2.1.1 for this module); the vendored OpenHTML module keeps its explicit LGPL-2.1+ entry (a child's <licenses> replaces the parent's); the seven modules that had no license (renderer, bridges/renderer, record-files, printing, remote-renderer parent/transport/adapter) now inherit the root's Apache-2.0, matching the repository LICENSE. - compiler: build-parent adds <source>21</source><target>21</target> to the compiler plugin; identical to the modules' maven.compiler.release 21; the Java 8 vendor module pins <source>8</source><target>8</target> explicitly next to maven.compiler.release 8 (testRelease 21 unchanged). - dependency management: build-parent imports qqq-bom-pom 4.0.0 (jackson 2.21.5, qqq 4.0.0, ...) which the parentless modules never had. record-files and printing now import qqq-bom-pom ${qqq.version} (as foundation and bridges/scripting already do), so their managed versions equal what qqq-backend-core RC.21 declares; renderer, bridges/renderer and remote-renderer-parent import jackson-bom 2.22.4 so jackson-core/annotations stay aligned with their explicit jackson-databind 2.22.4. - guardrails: build-parent 2.1.1 adds the qbit-guardrails test dependency, surefire dependenciesToScan and enforcer executions. foundation keeps them (enforcer.skip false); the other modules keep the previous behavior (enforcer.skip true, dependenciesToScan reset); the extra test-scope qbit-guardrails dependency and the snapshots-only central-portal-snapshots repository are inherited metadata. - url/scm: the root states build-parent's url/scm so the modules' derived metadata stays the same. The vendor's complete-source ZIP now ships parent/pom.xml (a copy of the reactor POM; module/pom.xml differs from the repository POM only in its relativePath, ../parent/pom.xml inside the archive), inputs.sha256 and the verify/build scripts follow, the README documents it, and renderer/Dockerfile copies the reactor POM from a named BuildKit context. Not built or tested: model introspection only. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>