SLING-13253 - finalize: update the Sling website as the last step

[royteeuwen]

Stack: 2 of 3 — builds on #47 (JGit upgrade); #48 builds on this. Review #47 first.

Promoting a release also requires updating the website, which finalize did not do. UpdateLocalSiteCommand already edited releases.md and downloads.tpl, but it only printed a git diff — so nothing it produced ever landed.

finalize now orchestrates that command as step 6/6, reusing its editing and commit/push helpers rather than reimplementing them, following the existing planDistRelease / publishToDistRelease pattern. The checkout is cloned from gitbox so the same ASF credentials that already commit to dist.apache.org can push.

Downloads entries are matched on the artifact id

Matching on the display name silently did nothing for roughly a third of releases, because the name on the downloads page regularly differs from the released component name:

Release	downloads.tpl entry
Commons Mime	Commons Mime Type Service
Tracer	Log Tracer
Event Impl	Event
Webconsole Security Provider	Web Console Security Provider
Installer Configuration Factory	Installer Configuration Support
Testing OSGi Mock	Testing OSGi Mock Core + JUnit 4 + JUnit 5 (3 entries)

The old regex also excluded digits, so I18n, osgi-mock.junit4/5, metrics-rrd4j and auth.saml2 could never match, and the change count it returned was discarded by the caller — so the no-op was invisible.

Entries are now keyed on the artifact id, which is also what the site's own renovate.json keys on. Artifact ids come from the staged POMs, or from the released POMs in dist/release once the staging repository has been dropped, so this works both before and after promotion. Since a release name maps to its child modules only through the <parent> chain, that resolution reuses PomParser instead of guessing.

Only entries on the same major version are rewritten

dist/release keeps several major streams published side by side while the downloads page lists a single, latest-major entry per artifact — resourceresolver is listed at 2.0.2 while 1.12.16 is still distributed, and nine artifacts are currently in that state. Matching on the artifact id alone would therefore have turned a Resource Resolver 1.12.18 maintenance release into a downgrade of the 2.x entry. A maintenance release of an older line now reports that the page tracks another major version and touches nothing. Composite versions (4.1.0-1.86.0, 7.0.5-2.8.2) and the Groovy ${starterVersion} interpolation are handled too.

An artifact with no entry at all is reported so it can be added by hand — which is what the release guide asks for when a brand new module is released.

The news page stays manual

A new release update-news command adds an announcement entry. It is deliberately not part of finalize, since the release guide only asks for a news entry when a release warrants an announcement.

Notes

• The display-name based updateDownloads is removed in the second commit; it had no callers left, since the --release path also resolves artifact ids.
• FinalizeCommandTest was cloning the real sling-site and attempting an actual push to gitbox — it "passed" only because the step warns rather than fails. That is now stubbed, so no test touches the network.
• A step 6 failure is warned about but does not fail finalize: everything irreversible has already succeeded by that point.

Verification

Beyond the unit tests, the flow was replayed against a real past release (Event Impl 4.4.2, which the page lists as Event — the display-name mismatch case): the generated downloads.tpl is byte-identical to the human commit that released it (blob c44750814…), with the push directed at a local repository standing in for gitbox.

Companion docs update: apache/sling-site#286.

---

CI note: continuous-integration/jenkins/pr-merge fails on this PR for an infrastructure reason, not a code one. The ASF Jenkins job merges the PR head into its target branch, but it only fetches master, so a base of feature/SLING-13253-upgrade-jgit cannot be resolved:

git merge <base> -> "not something we can merge"

Because Jenkins also triggers the SonarCloud analysis, this PR has no fresh Sonar run either. CI will go green once its base lands on master and GitHub retargets this PR. Locally, mvn clean verify passes on this branch.

[royteeuwen]

@raducotescu as requested ;), did i miss anything or is everything now fully automated?

[rombert]

I think there are multiple changes in this PR, and it would be good to be able to review them independently. Maybe with https://docs.github.com/en/pull-requests/get-started/stacked-prs-quickstart ?

[royteeuwen]

I think there are multiple changes in this PR, and it would be good to be able to review them independently. Maybe with https://docs.github.com/en/pull-requests/get-started/stacked-prs-quickstart ?

Done :D give it a try and let me know if you find it better :)

[rombert]

Thanks, indeed easier to review

[royteeuwen]

Thanks @rombert — all four points addressed in 819df9c:

Comment	Change
reusable code out of UpdateDistCommand	new DistRepository in org.apache.sling.cli.impl.dist; commands call it instead of each other
env var vs CLI argument	--site-checkout option, threaded as a parameter; env var removed entirely
unrelated DateProvider change	it is a Sonar java:S8688 fix (explicit time zone); explained inline, happy to split it out
heavy mocking in the tests	both site test classes now run against a real repository via a SiteRepository rule

The mocking one was worth doing: the real-repository tests immediately caught that the commit was recording the wrong committer identity, which the mocked version could not see.

Note the stack has grown a layer, since the review feedback sits below the shallow-clone work: #47 (merged) → #40 → #48.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
86.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rombert]

LGTM, thanks!