ammachado commented on PR #1700:
URL: https://github.com/apache/camel-website/pull/1700#issuecomment-5047393570
Companion upstream PR: apache/camel#25030. It lands all of these in
apache/camel `main`, which resolves both coordination points here. Sequencing
matters though: #25030 needs to merge before this PR (or before the next
`update-camel-cli-manifest.sh` run), otherwise the divergence you flagged is
real.
On the byte-identical concern: #25030 adds the three pieces to the upstream
generator that were previously only vendored here — the `LICENSE_HEADER`
constant, `renderManifest()` prepending it, and the `parseStrictManifest()`
`#`-skip. Once it merges, `scripts/WebsiteManifestGenerator.java` is
byte-identical to the upstream source again (bar the vendored-copy banner), so
the "re-copy, re-apply banner" model stops silently dropping changes.
On the installer clobbering: #25030 also adds the `#`-comment tolerance to
upstream `install.sh` (`case \#*) continue`) and `install.ps1` (`Where-Object {
-not $_.StartsWith('#') }`). So after it merges, step 1 of
`update-camel-cli-manifest.sh` fetches installers that already skip the `##`
license header the Java generator writes. I also synced `static/install.sh`
here with a small upstream robustness change (surfacing wget/tar errors) to
keep the vendored copy identical to what #25030 publishes.
Given the ordering dependency, does it make sense to hold this PR until
#25030 is merged?
_Claude Code on behalf of ammachado_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
