Merge branch 'master' into docs/remove-rack-references-275

Author: tuxmea

_data/openvoxdb_release_contents/openvox_8x.yml

@@ -1,5 +1,11 @@
 ---
+- release: 8.14.1
+  jetty: 12.1.10
 - release: 8.14.0
+  jetty: 12.1.10
 - release: 8.13.0
+  jetty: 10.0.26
 - release: 8.12.1
+  jetty: 10.0.26
 - release: 8.12.0
+  jetty: 10.0.26

_data/server_release_contents/openvox_8x.yml

@@ -1,4 +1,6 @@
 ---
+- release: 8.14.1
+  jruby: 9.4.12.1
 - release: 8.14.0
   jruby: 9.4.12.1
 - release: 8.13.0

docs/_ecosystem_8x/devkit/migrating.md

@@ -16,18 +16,22 @@ If you get an error about a command not being available, you probably just need
 
 {% include alert.html type="tip" content="There are a few exceptions to this pattern. For example, Jig is an installed package and VoxBox is a Docker container." %}
 
-| You used to type... | Now you type...  |
-|---------------------|------------------|
-| `pdk new module`    | `jig new module` |
-| `pdk new class`     | `jig new class`  |
-| `pdk build`         | `jig build`      |
-| `pdk release`       | `jig release`    |
-| `pdk convert`       | _not needed_     |
-| `pdk update`        | `jig update`     |
-| `pdk validate`      | `jig validate`   |
-| `pdk test unit`     | `jig test unit`  |
-
-`jig update`, `jig validate`, and `jig test unit` are thin wrappers around `bundle exec msync update`, `bundle exec rake validate lint`, and `bundle exec rake spec` respectively, so they still need the module's gems installed (`bundle install`).
-You can keep running the underlying `bundle exec` commands directly if you prefer.
+Jig also contains thin wrappers around the `bundle exec` commands, so in many cases you can use the CLI patterns you're used to typing.
+Because Jig does not attempt to hide the Bundler environment from you, it will still need the module's gems installed (`bundle install`) and ModuleSync configured properly.
+
+{% include alert.html type="tip" title="Choosing command forms" content="If you want quick and familiar commands to run locally, then use the Jig wrapper commands. If you're running tests and such in CI or if you need to pass custom options then invoke the tools directly." %}
+
+| You used to type... | Now you type...  | Or run tools directly...         |
+|---------------------|------------------|----------------------------------|
+| `pdk new module`    | `jig new module` |                                  |
+| `pdk new class`     | `jig new class`  |                                  |
+| `pdk build`         | `jig build`      |                                  |
+| `pdk release`       | `jig release`    |                                  |
+| `pdk convert`       | _not needed_     |                                  |
+| `pdk update`        | `jig update`*    | `bundle exec msync update`*      |
+| `pdk validate`      | `jig validate`   | `bundle exec rake validate lint` |
+| `pdk test unit`     | `jig test unit`  | `bundle exec rake spec`          |
+
+{% include alert.html type="note" title="*NOTE" content="`pdk update` operates in context of a single module. In contrast, the replacement ModuleSync commands (`jig update` and `bundle exec msync update`) should be run in the template repository to push updates to all your modules at once. [Read more](modulesync.html)." %}
 
 Browse through the individual subpages of this Developer Tooling section to learn more about each component.

docs/_openvox_8x/component_versions.md

@@ -26,11 +26,10 @@ on its own 5.x line). There is no single "OpenVox platform version" that pins al
 of them at once, so each component is shown in its own table, keyed by that
 component's release.
 
-The bundled-component columns are **generated** from upstream release metadata (the
-per-release SBOMs published by [openvox-sbom-tools][sbom_tools] for the agent and
-OpenBolt, and component pins for the server), so they don't drift. Columns that
-aren't bundled or pinned anywhere (Java and PostgreSQL) are supported-version
-requirements maintained by hand; see the note under each table.
+The bundled-component columns are **generated** from the per-release SBOMs published
+by [openvox-sbom-tools][sbom_tools] for every component, so they don't drift. Columns
+that aren't bundled anywhere (Java and PostgreSQL) are supported-version requirements
+maintained by hand; see the note under each table.
 
 <!-- markdownlint-disable MD055 MD056 -->
 
@@ -48,8 +47,8 @@ changes; this page is only a pointer.
 
 ## Server components
 
-These ship with the `openvox-server` package. JRuby is the bundled version,
-resolved from the server's pinned `jruby-utils`/`jruby-deps`.
+These ship with the `openvox-server` package. JRuby is the bundled version, read
+from the server's per-release SBOM.
 
 | OpenVox Server release | JRuby | Java |
 | --- | --- | --- |
@@ -67,15 +66,19 @@ OpenVoxDB ships in the `openvoxdb` package on its own release line. The
 agents talk to OpenVoxDB) is released in lockstep at the **same version** as
 `openvoxdb`, so it is not listed separately.
 
-| OpenVoxDB release | PostgreSQL |
-| --- | --- |
-{% for r in site.data.openvoxdb_release_contents[nav_key] %}| {{ r.release }} | 11+ (14+ recommended) |
+Jetty is the bundled HTTP server, read from the OpenVoxDB SBOM.
+
+| OpenVoxDB release | Jetty | Java | PostgreSQL |
+| --- | --- | --- | --- |
+{% for r in site.data.openvoxdb_release_contents[nav_key] %}| {{ r.release }} | {{ r.jetty }} | 11, 17 | 11+ (14+ recommended) |
 {% endfor %}
 
-> **PostgreSQL is not bundled.** OpenVoxDB connects to a PostgreSQL server you
-> install separately (the `puppet-openvoxdb` module can install it for you). The
-> PostgreSQL column shows the supported minimum (PostgreSQL 11; version 14 or newer
-> recommended), not a per-release pin; see [Configuring PostgreSQL][openvoxdb_postgres].
+> **Java and PostgreSQL are not bundled.** OpenVoxDB runs on a JVM and connects to a
+> PostgreSQL server you install separately (the `puppet-openvoxdb` module can install
+> PostgreSQL for you). The Java column shows the currently supported major versions,
+> and the PostgreSQL column the supported minimum (PostgreSQL 11; version 14 or newer
+> recommended) — neither is a per-release pin. See
+> [Configuring PostgreSQL][openvoxdb_postgres].
 
 ## OpenBolt
 

lib/puppet_references/release_tables.rb

@@ -12,9 +12,8 @@ module PuppetReferences
   # drive the table and resolves one row per stable release from authoritative,
   # structured metadata, so the tables are never hand-maintained. The shared
   # GitHub releases/contents plumbing lives here so the per-table classes stay
-  # small. Agent and OpenBolt rows come from openvox-sbom-tools SBOMs (see
-  # SbomReleaseTable); server and OpenVoxDB rows are still resolved from upstream
-  # pins until their SBOMs land.
+  # small. Every table now sources its bundled-component columns from
+  # openvox-sbom-tools SBOMs (see SbomReleaseTable).
   #
   # Authenticates with ENV GITHUB_TOKEN/GH_TOKEN, falling back to `gh auth token`
   # for local runs. A release whose components can't be resolved (e.g. a tag that
@@ -210,52 +209,45 @@ def columns
     end
   end
 
-  # openvox-server: bundled JRuby, resolved through the server's pinned
-  # jruby-utils -> jruby-deps "9.4.12.1-3" (the trailing "-N" packaging suffix is
-  # stripped). Java is a supported requirement, not a pin, so it is hand-maintained
-  # on the docs page rather than resolved here. Stays on the upstream-pin scraper
-  # until an openvox-server SBOM is published.
-  class ServerReleaseTable < ReleaseTable
-    SERVER_REPO = 'OpenVoxProject/openvox-server'
-    JRUBY_UTILS_REPO = 'OpenVoxProject/jruby-utils'
+  # openvox-server: bundled JRuby, read from the openvox-server SBOM's `jruby-base`
+  # component (the resolved JRuby version). This replaces the previous resolution
+  # through the server's pinned jruby-utils -> jruby-deps in project.clj, which
+  # required stripping a "-N" packaging suffix; `jruby-base` is already clean. Java
+  # is a supported requirement, not a pin, so it is hand-maintained on the docs
+  # page rather than resolved here.
+  class ServerReleaseTable < SbomReleaseTable
+    REPO = 'OpenVoxProject/openvox-server'
 
     def repo
-      SERVER_REPO
-    end
-
-    def row_for(tag, cache)
-      jruby_utils = pin_in_project_clj(SERVER_REPO, tag, 'jruby-utils')
-      { 'release' => tag, 'jruby' => (cache[jruby_utils] ||= jruby_from_utils(jruby_utils)) }
+      REPO
     end
 
-    private
-
-    def jruby_from_utils(jruby_utils_ver)
-      deps = pin_in_project_clj(JRUBY_UTILS_REPO, jruby_utils_ver, 'jruby-deps')
-      deps.sub(/-\d+\z/, '')
+    def sbom_package
+      'openvox-server'
     end
 
-    # Version of an org.openvoxproject/<name> dependency pinned in a repo's project.clj.
-    def pin_in_project_clj(repo, ref, name)
-      clj = raw(repo, 'project.clj', ref)
-      version = clj[%r{org\.openvoxproject/#{Regexp.escape(name)}\s+"([^"]+)"}, 1]
-      raise NotFound, "#{name} pin in #{repo}@#{ref}" unless version
-
-      version
+    def columns
+      { 'jruby' => 'jruby-base' }
     end
   end
 
-  # OpenVoxDB ships on its own independent version line; the table is just its
-  # stable release tags. PostgreSQL is a supported requirement (the openvoxdb
-  # module only declares a postgresql dependency range, not a bundled version),
-  # so it is hand-maintained on the docs page.
-  class OpenvoxdbReleaseTable < ReleaseTable
+  # OpenVoxDB ships on its own independent version line. It is a Clojure/JVM
+  # service (no bundled JRuby), so the one bundled component worth surfacing is the
+  # embedded Jetty HTTP server, read from its per-release SBOM. Java and PostgreSQL
+  # are supported requirements (the openvoxdb module only declares a postgresql
+  # dependency range, not a bundled version), so those columns stay hand-maintained
+  # on the docs page.
+  class OpenvoxdbReleaseTable < SbomReleaseTable
     def repo
       'OpenVoxProject/openvoxdb'
     end
 
-    def row_for(tag, _cache)
-      { 'release' => tag }
+    def sbom_package
+      'openvoxdb'
+    end
+
+    def columns
+      { 'jetty' => 'jetty-server' }
     end
   end
 end