feat: migrate from GraalVM Native Image to JAR distribution #309
Conversation
Complete migration from platform-specific native binaries to universal JAR bundle distribution. Major Changes: - Distribution: Single JAR bundle (~20MB) replacing 6 platform binaries (~260MB) - Runtime: Now requires Java 21+ instead of platform-specific native executables - Build: Shadow JAR plugin replaces GraalVM Native Image compilation - CI/CD: Simplified workflow building universal JAR instead of multi-platform binaries - SBOM: Dual-level approach (source + binary SBOMs) Documentation Updates: - Renamed install-jar.ps1 → install.ps1 for consistency - Removed obsolete native binary docs (install/README.md, install/verify-README.md) - Updated SBOM verification guide for JAR bundle structure - Updated security verification guides with JAR-specific instructions - Created ADR-0017 documenting migration rationale Technical Cleanup: - Removed GraalVM Native Image configuration files - Removed platform-specific build workflows - Cleaned up obsolete environment variables - Updated all documentation references 🤖 Generated with [Claude Code](https://claude.ai/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 021df9c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughMigrates the project from GraalVM Native Image to a universal Shadow fat JAR distribution. Removes GraalVM native-image plugins, configs, and multi‑platform CI jobs; adds Shadow JAR build, wrapper scripts (Unix/Windows/PowerShell), JAR-focused release workflow, installers, and documentation requiring Java 21+. Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant W as Wrapper (bin/scopes)
participant J as scopes.jar
participant JVM as Java Runtime
U->>W: run scopes [args]
activate W
W->>W: locate scopes.jar
W->>W: verify Java installed & version >= 21
W->>W: load SCOPES_JAVA_OPTS / JAVA_OPTS / config
W->>JVM: java [opts] -jar scopes.jar [args]
deactivate W
activate J
J->>JVM: application runs
JVM-->>U: stdout / exit code
sequenceDiagram
participant Build as build-jar
participant Hash as collect-hashes
participant Prov as provenance
participant Dist as create-jar-distribution
participant Rel as create-release
Build->>Build: compile & shadowJar -> scopes.jar
Build->>Hash: emit jar_hash
par
Prov->>Prov: generate SLSA provenance for scopes.jar
Hash->>Hash: collect/encode jar_hash
end
Dist->>Dist: bundle scopes.jar + wrappers + SBOMs + checksums
Dist-->>Rel: upload jar-distribution-bundles
Prov-->>Rel: upload provenance.json
Hash-->>Rel: provide hash for SLSA
Rel->>Rel: publish GitHub release with artifacts
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes
Possibly related PRs
Suggested labels
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (13)
💤 Files with no reviewable changes (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (2)
🧰 Additional context used📓 Path-based instructions (5)docs/**📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
docs/**/*.md📄 CodeRabbit inference engine (CLAUDE.md)
Files:
**/*.{kt,kts}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
{gradle/libs.versions.toml,settings.gradle.kts,**/build.gradle.kts}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
{**/build.gradle.kts,gradle.properties}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
🧠 Learnings (1)📚 Learning: 2025-08-25T14:25:43.702ZApplied to files:
🪛 Gitleaks (8.28.0)docs/explanation/security/sbom-verification.md[high] 122-123: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource. (curl-auth-header) 🪛 LanguageTooldocs/explanation/adr/0017-jvm-jar-distribution-strategy.md[grammar] ~253-~253: Ensure spelling is correct (QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1) [style] ~260-~260: Consider an alternative to avoid wordiness and to strengthen your wording. (WORKS_WITHOUT_PROBLEMS) ⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
🔇 Additional comments (29)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Snapshot WarningsEnsure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice. OpenSSF Scorecard
Scanned Files
|
Summary of ChangesHello @kamiazya, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request completes the strategic migration from platform-specific GraalVM Native Image binaries to a universal JAR distribution, as outlined in ADR-0017. This change simplifies the build system, reduces distribution size, and enhances the user and developer experience by leveraging standard JVM capabilities, albeit introducing a Java 21+ runtime dependency. This move unblocks future gRPC-based daemon communication and aligns the project with industry-standard JVM distribution practices. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
install/install.sh
Outdated
| # Check if hash file exists | ||
| HASH_FILE="$SCRIPT_DIR/verification/scopes.jar.sha256" | ||
| if [ ! -f "$HASH_FILE" ]; then | ||
| print_warning "Hash file not found, skipping verification" | ||
| return | ||
| fi | ||
|
|
||
| print_status "Verifying SHA256 hash..." | ||
|
|
||
| # Verify hash | ||
| if command -v sha256sum &> /dev/null; then | ||
| echo "$(cat "$HASH_FILE") $JAR_FILE" | sha256sum -c - || { | ||
| print_error "Hash verification failed" | ||
| exit 1 | ||
| } | ||
| elif command -v shasum &> /dev/null; then | ||
| echo "$(cat "$HASH_FILE") $JAR_FILE" | shasum -a 256 -c - || { | ||
| print_error "Hash verification failed" |
There was a problem hiding this comment.
In the new JAR installer the integrity check builds the command with echo "$(cat "$HASH_FILE") $JAR_FILE" | sha256sum -c -. Because the hash file already contains "<digest> scopes.jar", appending the absolute JAR path produces a line like "<digest> scopes.jar /usr/local/lib/scopes.jar" which sha256sum/shasum reject as improperly formatted. On systems that have these tools (the default on most Linux/macOS installs) the script exits before copying files, so installation always fails despite a valid JAR. The command needs to substitute the filename in the checksum record with the target path instead of appending a second token.
Useful? React with 👍 / 👎.
| # Verify installation | ||
| function Test-InstallationFiles { | ||
| Write-Header "Verifying Installation" | ||
|
|
||
| $binaryPath = Join-Path $InstallDir "scopes.exe" | ||
|
|
||
| if (-not (Test-Path $binaryPath)) { | ||
| Write-ErrorMsg "Installation verification failed: binary not found at $binaryPath" | ||
| return $false | ||
|
|
||
| # Check if hash file exists | ||
| $hashFile = Join-Path $ScriptDir "verification\scopes.jar.sha256" | ||
| if (-not (Test-Path $hashFile)) { | ||
| Write-Warn "Hash file not found, skipping verification" | ||
| return | ||
| } | ||
|
|
||
| Write-Status "Verifying SHA256 hash..." | ||
|
|
||
| try { | ||
| $expectedHash = (Get-Content $hashFile).Trim() | ||
| $actualHash = (Get-FileHash -Path $JarFile -Algorithm SHA256).Hash | ||
|
|
||
| if ($actualHash -ne $expectedHash) { | ||
| Write-Err "Hash verification failed" | ||
| Write-Host "Expected: $expectedHash" | ||
| Write-Host "Actual: $actualHash" |
There was a problem hiding this comment.
Test-InstallationFiles reads scopes.jar.sha256 with Get-Content and compares the raw line to the digest from Get-FileHash. A checksum file created with sha256sum includes the filename after the hash (e.g. "<digest> scopes.jar"), so $expectedHash contains both fields and can never equal the digest string returned by Get-FileHash. Whenever the verification file exists the script reports "Hash verification failed" and aborts installation even for valid artifacts. The code should parse just the first whitespace-separated field from the checksum file before doing the comparison.
Useful? React with 👍 / 👎.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This is a significant and well-executed migration from GraalVM native images to a standard JAR distribution. The changes are comprehensive, covering the build system, adding cross-platform wrapper scripts, and extensively updating the documentation to reflect this new strategy. The new ADR provides excellent context for the decision. I've identified a few minor issues related to consistency and robustness in the new scripts and documentation, which are detailed in the review comments. Overall, this is a great improvement that simplifies the build process and aligns the project with standard JVM distribution practices.
bin/scopes
Outdated
| fi | ||
|
|
||
| # Check Java version (robust extraction for EA builds and vendor variations) | ||
| JAVA_VERSION=$(java -version 2>&1 | sed -E -n 's/.*version "([0-9]+).*/\1/p' | head -n 1) |
There was a problem hiding this comment.
The current sed command for Java version parsing is not robust for versions older than 9 (e.g., Java 8), as it won't match the 1.x format. This causes the script to issue a generic warning and proceed, which could lead to runtime errors. Using a more robust awk-based approach ensures that older Java versions are correctly identified and a proper error is shown, improving user experience and consistency with the other wrapper scripts.
JAVA_VERSION=$(java -version 2>&1 | grep 'version' | awk -F'"' '{print $2}' | awk -F. '{if ($1 == "1") print $2; else print $1}')
bin/scopes.bat
Outdated
| REM Load Java options from environment variables | ||
| REM Priority: SCOPES_JAVA_OPTS > JAVA_OPTS | ||
| set "JAVA_OPTIONS=" | ||
| if defined JAVA_OPTS ( | ||
| set "JAVA_OPTIONS=%JAVA_OPTS%" | ||
| ) | ||
| if defined SCOPES_JAVA_OPTS ( | ||
| set "JAVA_OPTIONS=%SCOPES_JAVA_OPTS%" | ||
| ) |
There was a problem hiding this comment.
The bash and PowerShell wrapper scripts support loading JAVA_OPTS from a scopes.conf configuration file, but this batch script only supports environment variables. For feature consistency across platforms, support for reading from a configuration file (e.g., %APPDATA%\scopes\scopes.conf) should be added, maintaining the override priority of SCOPES_JAVA_OPTS > JAVA_OPTS > config file.
REM Load Java options from config file, then environment variables
REM Priority: SCOPES_JAVA_OPTS > JAVA_OPTS > config file
set "JAVA_OPTIONS="
REM Check for config file in standard locations
set "CONFIG_FILE="
if exist "%APPDATA%\scopes\scopes.conf" (
set "CONFIG_FILE=%APPDATA%\scopes\scopes.conf"
) else if exist "%USERPROFILE%\.scopes\scopes.conf" (
set "CONFIG_FILE=%USERPROFILE%\.scopes\scopes.conf"
)
if defined CONFIG_FILE (
for /f "usebackq tokens=1,* delims==" %%a in ("%CONFIG_FILE%") do (
if /i "%%a"=="JAVA_OPTS" (
set "TEMP_OPTS=%%b"
set "JAVA_OPTIONS=!TEMP_OPTS:"=!!"
)
)
)
REM Override with environment variables
if defined JAVA_OPTS (
set "JAVA_OPTIONS=%JAVA_OPTS%"
)
if defined SCOPES_JAVA_OPTS (
set "JAVA_OPTIONS=%SCOPES_JAVA_OPTS%"
)
| fi | ||
|
|
||
| # Extract major version number (handles both old and new version formats, EA builds, and vendor variations) | ||
| JAVA_VERSION=$(java -version 2>&1 | sed -E -n 's/.*version "([0-9]+).*/\1/p' | head -n 1) |
There was a problem hiding this comment.
The current sed command for Java version parsing is not robust for versions older than 9 (e.g., Java 8). It will fail to extract the version, causing the script to exit with a generic "Could not determine Java version" error. Using a more robust awk-based approach would provide a more accurate error message to the user, indicating that their Java version is too old.
| JAVA_VERSION=$(java -version 2>&1 | sed -E -n 's/.*version "([0-9]+).*/\1/p' | head -n 1) | |
| JAVA_VERSION=$(java -version 2>&1 | grep 'version' | awk -F'"' '{print $2}' | awk -F. '{if ($1 == "1") print $2; else print $1}') |
| slsa-verifier verify-artifact scopes.jar \ | ||
| --provenance-path multiple.intoto.jsonl \ | ||
| --source-uri github.com/kamiazya/scopes |
There was a problem hiding this comment.
The command example for SLSA verification has an incorrect path to the provenance file. It should point to verification/multiple.intoto.jsonl inside the bundle, but the verification/ prefix is missing. This will cause the command to fail for users following the guide.
| slsa-verifier verify-artifact scopes.jar \ | |
| --provenance-path multiple.intoto.jsonl \ | |
| --source-uri github.com/kamiazya/scopes | |
| slsa-verifier verify-artifact scopes.jar \ | |
| --provenance-path verification/multiple.intoto.jsonl \ | |
| --source-uri github.com/kamiazya/scopes |
docs/tutorials/getting-started.md
Outdated
| ```bash | ||
| # Set version and platform (replace with actual values) | ||
| # Set version (replace with actual values) | ||
| VERSION="v0.1.0" # Check latest release at https://github.com/kamiazya/scopes/releases |
There was a problem hiding this comment.
The documentation uses inconsistent version placeholders across different files (e.g., v0.1.0, v1.0.0, vX.X.X). To avoid confusion and make it clear that this is a placeholder, it would be best to use a consistent, generic placeholder like vX.X.X across all documentation. This applies to the PowerShell example in this file as well.
| VERSION="v0.1.0" # Check latest release at https://github.com/kamiazya/scopes/releases | |
| VERSION="vX.X.X" # Check latest release at https://github.com/kamiazya/scopes/releases |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Nitpick comments (14)
.github/ISSUE_TEMPLATE/graalvm-config-cache-issue.md (1)
2-11: Deprecation approach is clear and well-communicated.The metadata updates (lines 2–5) and deprecation notice (lines 9–11) effectively signal that this template is obsolete. The redirect to the standard bug report template on line 11 helps users navigate to the appropriate current process.
Consider whether this template should be moved to an archived location (e.g.,
.github/ISSUE_TEMPLATE/archive/) rather than remaining in the active templates directory. This would prevent it from appearing in GitHub's issue creation UI while preserving it for historical reference. However, keeping it discoverable is also reasonable if you want users with legacy GraalVM issues to easily find the context.docs/reference/jni-config.md (1)
3-6: Deprecation banner reads well; add cross-links for migration context.Suggest linking ADR-0017 and the Java setup guide here to guide readers out of this deprecated page. Also consider marking the page as “Deprecated” in the nav/sidebar if your docs tooling supports it. As per coding guidelines.
bin/scopes.bat (2)
70-79: Parity and robustness for Java options and config (recommended).
- Read JAVA_OPTS from a config file like the Unix/PS1 wrappers (e.g., %APPDATA%\scopes\scopes.conf, %USERPROFILE%.scopes\scopes.conf).
- Preserve quoting in options (current splitting can break
-Dprop="a b"). Consider supporting Java argfiles (@file) to avoid fragile tokenization.Example additions:
REM Optional: load JAVA_OPTS from config for %%F in ("%APPDATA%\scopes\scopes.conf" "%USERPROFILE%\.scopes\scopes.conf") do ( if exist "%%~F" ( for /f "usebackq tokens=1,* delims==" %%K in ("%%~F") do ( if /I "%%~K"=="JAVA_OPTS" set "JAVA_OPTIONS=%%~L" ) goto :opts_loaded ) ) :opts_loadedArgfile pattern (requires writing to %TEMP% and passing
@filebefore-jar).
10-21: Allow overrides for JAR location and Java locator (optional).
- Support SCOPES_JAR and SCOPES_HOME to override discovery.
- If
where javafails, try%JAVA_HOME%\bin\java.exe.This improves portability on locked-down Windows images.
bin/scopes.ps1 (2)
117-125: Preserve quoting for Java options (use @argfile).
-split '\s+'breaks values with spaces (e.g.,-Dprop="a b"). Prefer Java’s argument files to avoid manual tokenization.Minimal change:
if ($JavaOptions) { $argFile = Join-Path $env:TEMP "scopes-java-opts.args" Set-Content -Path $argFile -NoNewline -Value $JavaOptions & java "@$argFile" -jar $JarFile @Arguments $exit = $LASTEXITCODE Remove-Item -ErrorAction SilentlyContinue $argFile exit $exit } else { & java -jar $JarFile @Arguments }
16-28: Add environment overrides for JAR discovery and JAVA_HOME fallback (optional).
- Check
$env:SCOPES_JARfirst; then$env:SCOPES_HOME\lib\scopes.jar.- If
Get-Command javafails, try& (Join-Path $env:JAVA_HOME 'bin\java.exe')when$env:JAVA_HOMEis set.Improves operability on enterprise Windows hosts.
bin/scopes (2)
102-108: Avoid fragile splitting of JAVA options (use Java @argfile).Passing
$JAVA_OPTIONSunquoted breaks quoted values. Prefer an argfile to preserve intended tokens.-if [ -n "$JAVA_OPTIONS" ]; then - # shellcheck disable=SC2086 - exec java $JAVA_OPTIONS -jar "$JAR_FILE" "$@" -else - exec java -jar "$JAR_FILE" "$@" -fi +if [ -n "$JAVA_OPTIONS" ]; then + ARGFILE="$(mktemp)" + printf '%s' "$JAVA_OPTIONS" > "$ARGFILE" + exec java "@$ARGFILE" -jar "$JAR_FILE" "$@" +else + exec java -jar "$JAR_FILE" "$@" +fi
12-24: Support env overrides for JAR discovery and JAVA_HOME fallback (optional).
- Prepend checks for
SCOPES_JARandSCOPES_HOME(e.g.,$SCOPES_HOME/lib/scopes.jar).- If
command -v javafails but$JAVA_HOMEis set, try"$JAVA_HOME/bin/java".Improves ergonomics across diverse environments.
SECURITY.md (1)
69-77: Minor clarity: name the SBOM/scanner tools for consistency.To align with migration notes, explicitly call out Syft and Grype:
- - Compiled JAR artifacts scanned with Grype + - Binary-level SBOM (CycloneDX) generated with Syft from compiled JAR artifacts + - Compiled JAR artifacts scanned with GrypeThis matches the “dual SBOMs (CycloneDX + Syft)” and “Grype scanning” described in the PR.
install/install.sh (1)
331-361: Fish shell PATH update uses bash syntax; won’t work in fish.Use fish-native commands when
$SHELLis fish.- fish) - PROFILE_FILE="$HOME/.config/fish/config.fish" - ;; + fish) + PROFILE_FILE="$HOME/.config/fish/config.fish" + ;; ... - echo "" >> "$PROFILE_FILE" - echo "# Added by Scopes installer" >> "$PROFILE_FILE" - echo "export PATH=\"$INSTALL_DIR/bin:\$PATH\"" >> "$PROFILE_FILE" + if [ "$SHELL_NAME" = "fish" ]; then + mkdir -p "$(dirname "$PROFILE_FILE")" + echo "" >> "$PROFILE_FILE" + echo "# Added by Scopes installer" >> "$PROFILE_FILE" + echo "set -gx PATH \"$INSTALL_DIR/bin\" \$PATH" >> "$PROFILE_FILE" + else + echo "" >> "$PROFILE_FILE" + echo "# Added by Scopes installer" >> "$PROFILE_FILE" + echo "export PATH=\"$INSTALL_DIR/bin:\$PATH\"" >> "$PROFILE_FILE" + fiinstall/install.ps1 (1)
128-157: Java version parsing: proceed-on-parse-fail weakens the requirement.If version can’t be parsed, we should fail closed instead of proceeding.
- } else { - Write-Warn "Could not parse Java version, proceeding anyway..." - } + } else { + Write-Err "Could not parse Java version. Scopes requires Java 21+." + exit 1 + } ... - } catch { - Write-Warn "Could not check Java version, proceeding anyway..." - } + } catch { + Write-Err "Could not check Java version. Ensure Java 21+ is installed." + exit 1 + }.github/workflows/release.yml (2)
226-229: Initialize file without bare redirection (SC2188).Use a no-op with redirection to satisfy shellcheck.
- # Initialize the combined hashes file - > combined-hashes.txt + # Initialize the combined hashes file + : > combined-hashes.txtStatic analysis flagged this (actionlint/shellcheck SC2188). Based on hints.
237-239: Quote outputs and avoid Useless Use of cat; also fix SC2086 risk.Safer and cleaner:
- HASHES_B64=$(cat combined-hashes.txt | base64 -w0) - echo "hashes=$HASHES_B64" >> $GITHUB_OUTPUT + HASHES_B64="$(base64 -w0 combined-hashes.txt)" + echo "hashes=$HASHES_B64" >> "$GITHUB_OUTPUT"actionlint hinted SC2086; this addresses it. Based on static analysis.
docs/explanation/adr/README.md (1)
252-253: ADR-0017 index entry looks good; consider adding it to the relationship diagram.Optional: extend the Mermaid graph with ADR-0017 and its links (e.g., to ADR-0006 Docs, ADR-0005 CLI).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (34)
.changeset/jar-distribution-docs-update.md(1 hunks).github/ISSUE_TEMPLATE/graalvm-config-cache-issue.md(1 hunks).github/workflows/build.yml(0 hunks).github/workflows/release.yml(10 hunks)SECURITY.md(2 hunks)apps/scopes/build.gradle.kts(2 hunks)apps/scopes/src/main/resources/META-INF/native-image/jni-config.json(0 hunks)apps/scopes/src/main/resources/META-INF/native-image/native-image.properties(0 hunks)apps/scopes/src/main/resources/META-INF/native-image/reflect-config.json(0 hunks)apps/scopes/src/main/resources/META-INF/native-image/resource-config.json(0 hunks)apps/scopes/src/main/resources/logback-native.xml(0 hunks)bin/scopes(1 hunks)bin/scopes.bat(1 hunks)bin/scopes.ps1(1 hunks)build.gradle.kts(0 hunks)docs/explanation/adr/0017-jvm-jar-distribution-strategy.md(1 hunks)docs/explanation/adr/README.md(1 hunks)docs/explanation/automated-release-process.md(4 hunks)docs/explanation/security/README.md(1 hunks)docs/explanation/security/sbom-verification.md(5 hunks)docs/explanation/security/security-verification.md(5 hunks)docs/explanation/setup/README.md(2 hunks)docs/explanation/setup/graalvm-setup.md(0 hunks)docs/explanation/setup/java-setup.md(1 hunks)docs/explanation/user-stories/0007-secure-manual-installation.md(10 hunks)docs/reference/jni-config.md(1 hunks)docs/tutorials/getting-started.md(1 hunks)gradle/libs.versions.toml(2 hunks)install/README.md(0 hunks)install/install.ps1(1 hunks)install/install.sh(1 hunks)install/offline/README.md(0 hunks)install/offline/install.sh(0 hunks)install/verify-README.md(0 hunks)
💤 Files with no reviewable changes (12)
- apps/scopes/src/main/resources/META-INF/native-image/resource-config.json
- apps/scopes/src/main/resources/META-INF/native-image/jni-config.json
- install/offline/README.md
- apps/scopes/src/main/resources/META-INF/native-image/reflect-config.json
- install/verify-README.md
- apps/scopes/src/main/resources/META-INF/native-image/native-image.properties
- install/README.md
- apps/scopes/src/main/resources/logback-native.xml
- docs/explanation/setup/graalvm-setup.md
- .github/workflows/build.yml
- build.gradle.kts
- install/offline/install.sh
🧰 Additional context used
📓 Path-based instructions (5)
docs/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Documentation under docs/ should follow the Diátaxis framework structure
Files:
docs/reference/jni-config.mddocs/explanation/security/sbom-verification.mddocs/explanation/adr/0017-jvm-jar-distribution-strategy.mddocs/tutorials/getting-started.mddocs/explanation/security/security-verification.mddocs/explanation/automated-release-process.mddocs/explanation/setup/java-setup.mddocs/explanation/user-stories/0007-secure-manual-installation.mddocs/explanation/setup/README.mddocs/explanation/security/README.mddocs/explanation/adr/README.md
docs/**/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
Write documentation in English (project’s official language)
Files:
docs/reference/jni-config.mddocs/explanation/security/sbom-verification.mddocs/explanation/adr/0017-jvm-jar-distribution-strategy.mddocs/tutorials/getting-started.mddocs/explanation/security/security-verification.mddocs/explanation/automated-release-process.mddocs/explanation/setup/java-setup.mddocs/explanation/user-stories/0007-secure-manual-installation.mddocs/explanation/setup/README.mddocs/explanation/security/README.mddocs/explanation/adr/README.md
**/*.{kt,kts}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{kt,kts}: Adhere to ktlint formatting rules for all Kotlin source and script files; run ktlintFormat before committing
Code must pass Detekt static analysis; avoid suppressing rules without clear justification
Files:
apps/scopes/build.gradle.kts
{gradle/libs.versions.toml,settings.gradle.kts,**/build.gradle.kts}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Do not modify dependencies to work around the JitPack/kulid resolution issue; keep declared dependencies unchanged until connectivity is restored
Files:
apps/scopes/build.gradle.ktsgradle/libs.versions.toml
{**/build.gradle.kts,gradle.properties}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Keep the project targeting Java 21 in Gradle configuration; do not downgrade the toolchain
Files:
apps/scopes/build.gradle.kts
🪛 actionlint (1.7.8)
.github/workflows/release.yml
181-181: shellcheck reported issue in this script: SC2086:info:2:41: Double quote to prevent globbing and word splitting
(shellcheck)
218-218: shellcheck reported issue in this script: SC2188:warning:9:1: This redirection doesn't have a command. Move to its command (or use 'true' as no-op)
(shellcheck)
218-218: shellcheck reported issue in this script: SC2086:info:20:30: Double quote to prevent globbing and word splitting
(shellcheck)
🪛 LanguageTool
docs/explanation/adr/0017-jvm-jar-distribution-strategy.md
[grammar] ~253-~253: Ensure spelling is correct
Context: ...ired) - Faster build times (30s vs 2-5min per platform) - Easier debugging (st...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[style] ~260-~260: Consider an alternative to avoid wordiness and to strengthen your wording.
Context: ... - Standard JVM networking libraries work without issues - Future IPC implementations unblock...
(WORKS_WITHOUT_PROBLEMS)
🪛 markdownlint-cli2 (0.18.1)
docs/explanation/adr/0017-jvm-jar-distribution-strategy.md
190-190: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
397-397: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/explanation/setup/java-setup.md
325-325: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Lint and Static Analysis
- GitHub Check: Unit Tests
- GitHub Check: Analyze (java-kotlin)
🔇 Additional comments (35)
bin/scopes.ps1 (1)
55-80: Version check logic is solid and resilient.Handles EA and legacy 1.x formats, and safely proceeds on parse failures. LGTM.
SECURITY.md (1)
58-61: All documentation links verified and correct.The relative paths in SECURITY.md (lines 58-61) all resolve successfully. No action required.
install/install.sh (1)
121-156: Java version parse is OK; consider stricter failure on unknown format.If parsing fails (Line 141), exiting is good. Keep as-is.
If you want EA builds support (e.g., “22-ea”), add fallback:grep -oE '"[0-9]+' | tr -dc 0-9. Do you want a patch?docs/explanation/security/README.md (1)
35-37: Good alignment with new installers; note current Windows hash bug.Docs state installers auto-verify SHA256 and SLSA. Linux path is correct; Windows will fail until the hash parsing fix lands (see install/install.ps1). No changes needed here.
.github/workflows/release.yml (1)
180-185: The review comment is based on an incorrect assumption and should be dismissed.The code correctly handles SLSA provenance, though for a different reason than the structure suggests:
The
jar_hashoutput at line 183 (custom formatscopes.jar:$JAR_HASH) is defined but never consumed by any downstream job.The actual SLSA integration occurs in the
collect-hashesjob (lines 210–218), which:
- Independently downloads the JAR artifact
- Recalculates the hash in the correct format:
"$JAR_HASH scopes.jar"(standard sha256sum format)- Base64 encodes this properly formatted output
- Passes it to the SLSA generator as
base64-subjectsThe provenance job receives correctly formatted input from
collect-hashes, not from the unusedjar_hashvariable.There is no format incompatibility with the SLSA generator because the problematic
jar_hashoutput is never used. The unused output is a code organization issue but does not affect correctness.Likely an incorrect or invalid review comment.
docs/explanation/setup/java-setup.md (1)
1-365: Excellent comprehensive Java setup guide.This document provides clear, platform-specific guidance with multiple installation options, troubleshooting, and advanced configuration. The structure follows the explanation/reference pattern appropriately with logical section progression and clear examples. Well-suited to support the migration away from GraalVM-specific setup requirements.
docs/explanation/setup/README.md (1)
8-8: Appropriate index updates reflecting Java setup migration.The setup directory index now correctly references the Java Setup guide (replacing GraalVM-focused content) and accurately documents that Java 21+ is required. Navigation is clear and consistent with the migration strategy.
Also applies to: 18-19
docs/explanation/security/sbom-verification.md (3)
15-19: Clarify SBOM format availability.Line 16 states "Format: JSON" but the surrounding context and ADR-0017 mention CycloneDX in both JSON and XML formats. Verify whether XML SBOMs are still provided as alternative formats or completely removed from the JAR distribution. If XML is removed, this should be explicitly stated. If retained, the format documentation should list both.
Search for references to SBOM XML format in release documentation or ADR-0017 to confirm whether XML is included in the JAR bundle distribution.
31-55: Bundle extraction and SBOM path consistency verified.The JAR bundle extraction instructions (lines 34-43 and 46-55) correctly reference the generalized SBOM paths (
sbom/scopes-sbom.jsonandsbom/scopes-binary-sbom.json) for both Linux/macOS and Windows PowerShell workflows. Terminology appropriately updated from platform-specific to JAR bundle.
69-104: SBOM analysis commands appropriately updated for JAR distribution.Commands for validating, scanning, and analyzing SBOMs (lines 72-145) now correctly reference the generalized SBOM file paths consistent with the JAR-only distribution model. Scanning tools (Grype, Syft) and Dependency-Track integration commands are properly updated.
.changeset/jar-distribution-docs-update.md (1)
1-43: Comprehensive and accurate migration changeset.The changeset clearly documents the GraalVM-to-JAR migration with proper breaking change notice, detailed technical changes (Shadow JAR plugin, wrapper scripts, CI/CD simplification), and balanced user impact analysis. All statements align with the PR objectives and related documentation updates. The benefits/requirements framing is appropriate for end-user communication.
gradle/libs.versions.toml (1)
37-37: Appropriate build plugin migration to Shadow JAR.The version catalog correctly introduces the Shadow plugin (
com.gradleup.shadowv8.3.6) which is the industry-standard Gradle plugin for creating fat JARs. The version is stable and well-maintained. Removal of GraalVM-related entries follows the migration strategy cleanly, and no conflicts exist with other declared dependencies.Also applies to: 94-94
docs/tutorials/getting-started.md (2)
16-23: Prerequisites clearly updated with Java 21+ requirement.The updated prerequisites (lines 16-18) appropriately add Java 21+ as a critical requirement with cross-reference to the Java Setup Guide. Line 23 provides clear context-setting note about JAR distribution and Java dependency. This sets proper expectations for users transitioning from native binaries.
112-125: Installation verification step appropriate for JAR context.The verification commands now correctly check for Scopes functionality (
scopes --version) after JAR installation, with example output that reflects the JAR-based distribution. This is the right verification approach for the new installation model.docs/explanation/adr/0017-jvm-jar-distribution-strategy.md (1)
69-210: Comprehensive and well-reasoned ADR for JAR distribution decision.ADR-0017 effectively documents the decision to migrate from GraalVM Native Image to a universal JAR distribution. The context clearly outlines the limitations of GraalVM (gRPC incompatibility, build complexity, development friction), and the decision is well-justified with industry-standard practices. The distribution strategy is concrete with clear implementation details, migration plan is phased and practical, and consequences are honestly balanced. The future enhancement section on modular JAR distribution shows forward thinking.
Minor: Fix two missing language identifiers in fenced code blocks (lines 190 and 397) per linting hints.
docs/explanation/user-stories/0007-secure-manual-installation.md (2)
1-112: User story successfully updated for JAR bundle installation.The user story title, terminology, and acceptance criteria have been consistently updated from platform-bundle to JAR bundle context. The Gherkin scenarios are comprehensive, testable, and appropriately focused on security verification of the JAR distribution. All platform-specific installer references have been replaced with universal JAR bundle + wrapper script approach, and the Java 21+ requirement is clearly stated in dependencies (line 164) and context.
The security features section (lines 174-192) appropriately emphasizes JAR hash verification and SLSA provenance for the new distribution model.
194-213: Implementation notes appropriately detail JAR bundle workflow.The platform support section now correctly documents bash/PowerShell scripts with Java 21+ requirement, and installation methods clearly show the tar/zip → extract → install workflow for both Unix and Windows platforms. This aligns with the overall JAR distribution strategy.
apps/scopes/build.gradle.kts (4)
1-8: Plugin migration from GraalVM to Shadow looks correct.The replacement of
alias(libs.plugins.graalvm.native)withalias(libs.plugins.shadow)is the right approach for this migration. Theapplicationplugin is preserved, which is correct for JAR-based applications.
87-109: Shadow JAR configuration is well-structured; clarify Multi-Release attribute necessity.The shadowJar task configuration appropriately handles fat JAR creation with service file merging (critical for Koin DI) and reasonable size optimizations. However, the
Multi-Releaseattribute on Line 95 is typically used for JARs with version-specific class files (e.g., Java 8, 11, 21 variants). Since this project targets Java 21 exclusively, verify whether this attribute is necessary or if it can be removed to simplify the manifest.#!/bin/bash # Verify if Multi-Release attribute serves a purpose in this codebase # Check for version-specific module-info or Java version-conditional compilation rg -n "module-info\|jpms\|java.base" --type=kotlin --type=java apps/scopes/ grep -r "sourceCompatibility\|targetCompatibility" gradle.properties build.gradle.kts apps/scopes/build.gradle.kts 2>/dev/null | head -20
104-108: JAR size optimization exclusions are appropriate.The exclusions of signature files (
*.SF,*.DSA,*.RSA) and license metadata from the shaded JAR are standard practice and won't affect functionality. This helps reduce the JAR size significantly while maintaining all functional classes and resources.
111-113: Build dependency on shadowJar ensures fat JAR is always produced.Adding the explicit dependency ensures the shadow JAR is built alongside the standard build task, which is correct for this distribution model.
docs/explanation/automated-release-process.md (6)
13-41: Mermaid diagrams effectively communicate the JAR-centric release workflow.The overview diagram clearly illustrates the three main job stages (Build JAR, Security Verification & SLSA, GitHub Release) and output types, making the migration from multi-platform native binaries to a universal JAR transparent. The styling and grouping are appropriate.
45-75: Build JAR Artifacts job flow is comprehensive and well-detailed.The step-by-step flow (Checkout → Setup Java 21 + Gradle → Extract Version → ... → Upload Artifacts) correctly captures the Shadow JAR build process with integrated SBOM and vulnerability scanning. The ordering and dependencies are logical.
77-111: JAR Security Scanning section properly integrates Grype and Syft.The scanning pipeline (Artifact Collection → Security Analysis → Results Integration) is appropriate for JAR-based verification. The distinction between Grype (vulnerability scanning) and Syft (SBOM generation) is clear.
113-139: Provenance generation section accurately reflects SLSA Level 3 integration.The use of JAR hash encoding for SLSA provenance is correct, and the flow clearly shows integration with the SLSA framework for cryptographic attestation.
141-181: GitHub Release Creation section comprehensively covers artifact organization.The diagram properly shows downloading all artifact types (JAR, SBOMs, scan results, provenance) before processing and publishing. The asset attachment and publication workflow is clear.
303-312: Verify all cross-referenced documentation files exist and have appropriate content.Line 312 references
../tutorials/getting-started.md, and earlier lines reference../guides/security-verification.mdand../guides/sbom-verification.md. Ensure these paths are correct relative to this file's location and that the referenced documents align with the JAR distribution model described here.#!/bin/bash # Verify cross-referenced documentation files exist # Check paths relative to docs/explanation/automated-release-process.md echo "Checking referenced files..." find docs -name "getting-started.md" -o -name "security-verification.md" -o -name "sbom-verification.md" | sort # Verify relative paths from docs/explanation/ cd docs/explanation 2>/dev/null && { echo "" echo "Relative paths from docs/explanation/:" ls -la ../tutorials/getting-started.md 2>/dev/null || echo "✗ ../tutorials/getting-started.md NOT FOUND" ls -la ../guides/security-verification.md 2>/dev/null || echo "✗ ../guides/security-verification.md NOT FOUND" ls -la ../guides/sbom-verification.md 2>/dev/null || echo "✗ ../guides/sbom-verification.md NOT FOUND" }docs/explanation/security/security-verification.md (8)
1-15: Documentation introduction appropriately emphasizes JAR-based security verification.The updated overview correctly positions SHA256 checksums and SLSA provenance as primary verification mechanisms for the universal JAR distribution, with SBOMs as supporting security inventory. This aligns well with the migration objectives.
18-49: Automated installation verification section provides clear, actionable guidance.The installer-based verification path is well-documented with platform-specific instructions (bash for Linux/macOS/WSL, PowerShell for Windows) and a clear bulleted list of what the installer performs (SHA256 check, SLSA verification, installation, PATH configuration). This lowers the barrier for users to verify before installation.
50-127: Manual verification instructions are comprehensive and platform-specific.The manual SLSA and SHA256 verification sections correctly guide users through:
- Installing slsa-verifier
- Extracting the JAR bundle
- Verifying the artifact
- Handling platform-specific variations (bash, shasum, PowerShell)
The expected output for successful verification is clearly documented. This allows users to verify without relying on the installer scripts.
129-139: SLSA verification scope and limitations are clearly articulated.The distinction between what SLSA confirms (source repository, commit hash, build environment, artifact integrity) and what it does not confirm (source code content, runtime behavior, dependency security) is important for user understanding and is well-explained.
212-240: Verify SBOM file paths and naming conventions match the build and release workflow.The SBOM verification section references specific file paths (
sbom/scopes-sbom.json,sbom/scopes-binary-sbom.json) and integration with tools likecyclonedxandgrype. Ensure these paths match what is actually generated by the Shadow JAR build process and published in the release workflow. Cross-check with.github/workflows/release.ymland thebuild.gradle.ktsCycloneDX plugin configuration.#!/bin/bash # Description: Verify SBOM paths and naming in build configuration echo "=== Checking build.gradle.kts for SBOM configuration ===" grep -n "cyclonedx\|sbom\|CycloneDX" apps/scopes/build.gradle.kts build.gradle.kts 2>/dev/null | head -20 echo "" echo "=== Checking release workflow for SBOM artifact naming ===" grep -n "sbom\|SBOM" .github/workflows/release.yml 2>/dev/null | head -20 echo "" echo "=== Checking for SBOM generation in tasks ===" rg -n "tasks\.|shadowJar\|cyclone" gradle/libs.versions.toml apps/scopes/build.gradle.kts --type=kotlin 2>/dev/null | grep -i sbom | head -20
217-240: SBOM verification examples are tool-appropriate and follow security standards.The use of
cyclonedx validatefor format validation andgrypefor vulnerability scanning against SBOM files demonstrates awareness of current security practices. Providing both source-level and binary-level SBOM examples is valuable for comprehensive dependency tracking.
190-210: Troubleshooting section appropriately handles common failure scenarios.The guidance for verification failures (detection of tampering/corruption), missing provenance, and tool installation issues is practical and escalation-appropriate (contact maintainers if provenance is missing from official releases).
18-49: Verify JAR bundle naming and download URLs are consistent with actual release workflow.The documentation references specific download URLs with bundle naming patterns (
scopes-vX.X.X-jar-bundle.tar.gz,scopes-vX.X.X-jar-bundle.zip) and includes installer script paths (./install.sh,.\install.ps1). Ensure these match the actual artifacts published by the release workflow and the directory structure of the distributed bundles.#!/bin/bash # Description: Verify JAR bundle naming and structure in release workflow echo "=== Checking release workflow for artifact naming ===" grep -n "scopes.*jar-bundle\|jar.bundle\|scopes.jar" .github/workflows/release.yml 2>/dev/null | head -30 echo "" echo "=== Checking for install script references ===" grep -n "install\\.sh\|install\\.ps1" .github/workflows/release.yml docs/explanation/security/security-verification.md 2>/dev/null | head -20 echo "" echo "=== Listing files in install/ and bin/ directories if they exist ===" find . -path "./install/*" -o -path "./bin/*" 2>/dev/null | head -30Also applies to: 82-127
| ## Security & Verification | ||
|
|
||
| This release includes SLSA Level 3 provenance and Software Bill of Materials (SBOM) for comprehensive supply chain security. | ||
| This release includes SLSA Level 3 provenance for supply chain security. | ||
|
|
||
| ### SLSA Provenance Verification | ||
| ```bash | ||
| # Install slsa-verifier | ||
| go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@latest | ||
|
|
||
| # Extract and verify from platform bundle | ||
| tar -xzf scopes-${{ needs.resolve-version.outputs.version }}-linux-x64-bundle.tar.gz | ||
| cd scopes-*-bundle | ||
| # Download the JAR and provenance | ||
| wget https://github.com/${{ github.repository }}/releases/download/${{ needs.resolve-version.outputs.tag_version }}/scopes-${{ needs.resolve-version.outputs.version }}-jar-bundle.tar.gz | ||
| wget https://github.com/${{ github.repository }}/releases/download/${{ needs.resolve-version.outputs.tag_version }}/multiple.intoto.jsonl | ||
|
|
||
| slsa-verifier verify-artifact scopes-${{ needs.resolve-version.outputs.version }}-linux-x64 \ | ||
| --provenance-path verification/multiple.intoto.jsonl \ | ||
| # Verify | ||
| slsa-verifier verify-artifact scopes-${{ needs.resolve-version.outputs.version }}-jar-bundle.tar.gz \ | ||
| --provenance-path multiple.intoto.jsonl \ | ||
| --source-uri github.com/${{ github.repository }} | ||
| ``` |
There was a problem hiding this comment.
SLSA verification instructions target tarball, but provenance is for the JAR only.
collect-hashes only includes scopes.jar, so the generated provenance covers the JAR, not the tar/zip bundles. The current notes will fail.
Two options:
- A) Quick doc fix (recommended now): verify
scopes.jarinstead of the tarball.
- # Download the JAR and provenance
- wget https://github.com/${{ github.repository }}/releases/download/${{ needs.resolve-version.outputs.tag_version }}/scopes-${{ needs.resolve-version.outputs.version }}-jar-bundle.tar.gz
- wget https://github.com/${{ github.repository }}/releases/download/${{ needs.resolve-version.outputs.tag_version }}/multiple.intoto.jsonl
-
- # Verify
- slsa-verifier verify-artifact scopes-${{ needs.resolve-version.outputs.version }}-jar-bundle.tar.gz \
- --provenance-path multiple.intoto.jsonl \
- --source-uri github.com/${{ github.repository }}
+ # Download the JAR and provenance
+ wget https://github.com/${{ github.repository }}/releases/download/${{ needs.resolve-version.outputs.tag_version }}/scopes.jar
+ wget https://github.com/${{ github.repository }}/releases/download/${{ needs.resolve-version.outputs.tag_version }}/multiple.intoto.jsonl
+
+ # Verify
+ slsa-verifier verify-artifact scopes.jar \
+ --provenance-path multiple.intoto.jsonl \
+ --source-uri github.com/${{ github.repository }}- B) Workflow change (later): include tar/zip hashes in subjects and generate provenance after bundles are created. I can draft that if you want.
🤖 Prompt for AI Agents
.github/workflows/release.yml around lines 620 to 637: the docs currently
instruct verifying the tarball but the provenance only covers scopes.jar
(collect-hashes included only the JAR), so update the verification command and
examples to target scopes.jar (e.g., download and verify scopes.jar and its
corresponding multiple.intoto.jsonl) to match the generated provenance;
alternatively, if you want the workflow change later, add bundle artifact hashes
to the subjects and generate provenance after bundle creation so tarball
verification is valid.
docs/reference/jni-config.md
Outdated
| ## Overview | ||
|
|
||
| The `jni-config.json` file in `/apps/scopes/src/main/resources/META-INF/native-image/` is required for GraalVM native image compilation when using SQLite JDBC driver. | ||
| The `jni-config.json` file in `/apps/scopes/src/main/resources/META-INF/native-image/` was required for GraalVM native image compilation when using SQLite JDBC driver. |
There was a problem hiding this comment.
Fix path prefix to avoid implying an absolute filesystem path.
Change “/apps/scopes/…” to a repo‑relative path.
-The `jni-config.json` file in `/apps/scopes/src/main/resources/META-INF/native-image/` was required for GraalVM native image compilation when using SQLite JDBC driver.
+The `jni-config.json` file in `apps/scopes/src/main/resources/META-INF/native-image/` was required for GraalVM native image compilation when using the SQLite JDBC driver.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| The `jni-config.json` file in `/apps/scopes/src/main/resources/META-INF/native-image/` was required for GraalVM native image compilation when using SQLite JDBC driver. | |
| The `jni-config.json` file in `apps/scopes/src/main/resources/META-INF/native-image/` was required for GraalVM native image compilation when using the SQLite JDBC driver. |
🤖 Prompt for AI Agents
In docs/reference/jni-config.md around line 9, the path shown for
jni-config.json uses a leading slash implying an absolute filesystem path
("/apps/scopes/..."); update it to a repo‑relative path by removing the leading
slash (e.g., "apps/scopes/src/main/resources/META-INF/native-image/...") so the
doc correctly references the file within the repository.
Add comprehensive protections against Gradle cache lint errors: - Add .gradle-local/ to .gitignore - Create scripts/clean-gradle-cache.sh for cleaning all Gradle caches - Update spotless configuration to exclude .gradle-local/** from all targets - Exclude package.json from spotless JSON formatting This prevents the 1079 lint errors that occurred in the previous commit when pre-commit hooks ran spotless checks on auto-generated Gradle cache files in .gradle-local/ directory. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Critical installer fixes: - Fix bash installer hash verification (extract checksum token properly) - Fix PowerShell installer hash verification (parse digest from hash file) - Update script name references in install.ps1 (install-jar.ps1 → install.ps1) Wrapper script improvements: - Improve Java version parsing in bash wrapper (support Java 8 format: 1.8.0_xxx) - Add config file support to batch wrapper (scopes.bat) - Guard Java version parsing in batch wrapper (handle parse failures gracefully) - Improve config parsing in bash wrapper (trim whitespace from key=value) - Enhance PowerShell wrapper error messages (add installation instructions) Documentation fixes: - Fix SLSA verification path (add missing verification/ prefix) - Standardize version placeholders (use vX.X.X consistently) - Update getting-started.md with correct install instructions - Add language identifiers to code blocks in ADR-0017 - Fix absolute path in jni-config.md (remove leading slash) All fixes address specific issues identified in AI code review: - Hash verification now works correctly on Linux/macOS/Windows - Java version detection handles both old (1.x) and new (21+) formats - Config file parsing is robust to whitespace and quotes - Documentation references are accurate and consistent 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
The jni-config.md document is no longer applicable after migration from GraalVM Native Image to JAR distribution. JNI configuration is not required for standard JVM execution with SQLite JDBC driver. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
kamiazya
changed the title
This file was only needed for GraalVM Native Image compilation and is no longer relevant after migrating to JAR distribution. Its presence was causing CodeQL Autobuild to fail with: - error: package org.graalvm.nativeimage.hosted does not exist Fixes CodeQL workflow failure on this branch.
Summary
Complete migration from platform-specific native binaries to universal JAR bundle distribution.
This PR implements the migration strategy documented in ADR-0017, replacing GraalVM Native Image compilation with a universal JAR distribution approach.
Breaking Changes
Before (Native Image)
After (JAR Distribution)
Major Changes
Distribution
Build System
Documentation
Security & Verification
Benefits
For Users
For Developers
Migration Guide
For End Users
For CI/CD
Testing
Changeset
This PR includes a changeset for patch release (0.0.5) documenting the migration.
Related
Test Plan
./gradlew clean :apps-scopes:shadowJar🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com
Summary by CodeRabbit
Breaking Changes
New Features
Documentation
Chores