adityamparikh commented on PR #157:
URL: https://github.com/apache/solr-mcp/pull/157#issuecomment-5341600407

   @epugh — I checked every concrete command in this against the repo as it 
stands on `main` (`a84033b`), so you can iterate on the prose without 
re-verifying the mechanics. Most of it holds up; there are two gaps that I 
think are the ones @janhoy's review is actually pointing at.
   
   ### Verified correct
   
   - `dev-docs/SMOKE_TEST.md` exists at exactly that path (landed in #158). ✅
   - The RAT check really is wired into `check`, and the plugin id is spelled 
correctly — `buildSrc/src/main/kotlin/org.apache.solr.mcp.rat.gradle.kts`. So 
"`./gradlew build` already ran it" is accurate, not aspirational. ✅
   - The `unzip -p build/libs/solr-mcp-X.Y.Z.jar META-INF/LICENSE` spot-check 
works — those files really are generated into the bootJar by 
`generateBinaryLicense`/`generateBinaryNotice`. ✅
   - Tag name `releases/solr-mcp/1.0.0` matches the `protected_tags: 
["releases/*"]` rule in `.asf.yaml`, so it will be protected on creation. ✅
   
   ### Gap 1 — nothing here produces a source release
   
   This is the big one. @janhoy's definition upthread was:
   
   > define a release as the src.tgz and binary.jar with shasum and asc 
signatures
   
   `./gradlew clean build` produces **no** `src.tgz`. I checked 
`build.gradle.kts` for any `Tar`/`distTar`/source-archive task and there is 
none. So an RM following these steps literally would upload a binary-only 
release, which is the one thing ASF policy does not allow — the source release 
is the formal artifact being voted on.
   
   Either a source-archive task needs adding to the build, or the doc needs an 
explicit manual step (e.g. `git archive --format=tar.gz 
--prefix=solr-mcp-1.0.0/ releases/solr-mcp/1.0.0 -o solr-mcp-1.0.0-src.tgz`).
   
   ### Gap 2 — `for fn in *.jar` signs four jars, not one
   
   `build.gradle.kts` calls both `withSourcesJar()` and `withJavadocJar()` 
alongside the bootJar and the plain jar, so after `clean build` the 
`build/libs/` directory holds roughly:
   
   ```
   solr-mcp-1.0.0.jar           <- bootJar (the fat/binary artifact)
   solr-mcp-1.0.0-plain.jar     <- thin jar
   solr-mcp-1.0.0-sources.jar
   solr-mcp-1.0.0-javadoc.jar
   ```
   
   The signing and `sha512` loops both glob `*.jar`, so they sign and checksum 
all four. Worth stating which of these are actually part of the release and 
being uploaded to ATR — an RM has no way to infer that "binary.jar" means the 
bootJar and not `-plain.jar`.
   
   Also: the loops imply the working directory is `build/libs` (the 
`../../gpgsign.sh` relative path only resolves from there), but that is never 
stated. And `gpgsign.sh` is not in this repo — worth saying where it comes 
from, since a first-time RM cannot find it.
   
   ### Smaller notes
   
   - `sha512` is not present on a stock macOS install (`shasum -a 512` is). My 
machine happens to have `/sbin/sha512`, so I could not reproduce the failure, 
but `shasum -a 512 "$fn" > "$fn.sha512"` is the spelling that works unmodified 
on both macOS and Linux and would let you drop the "use `sha512sum` on Linux" 
caveat.
   - Step 3 points at PR #136 for the `-SNAPSHOT` removal. Note #136 currently 
targets `main`, not a release branch — consistent with your comment there that 
it should go against `branch_1_0_0`. Might be worth stating in this doc that it 
gets retargeted, so the two documents do not disagree.
   
   Happy to send a PR against your branch with the source-archive step and the 
signing-scope clarification if that is useful, rather than you folding it in by 
hand — just say the word.
   


-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to