feat(processor): support no-arg @ServiceProvider via contract inference

[LMLiam]

Description

• Remove the Foojay toolchains settings plugin from settings.gradle to avoid mandatory plugin resolution during settings evaluation.
• Add support in the processor/annotation code for no-arg @ServiceProvider usage by giving ServiceProvider a default empty value and implementing inferContractsFromProvider in ServiceSchemeProcessor to BFS supertypes and collect @ServiceContract interfaces; emit a clear compilation error when none can be inferred.
• Add unit tests covering no-arg provider inference and the error case in ServiceSchemeProcessorSpec.kt.

---

Codex Task

---

Recreated from #13 — the original PR was auto-closed when main’s history was rewritten to the verb(scope): convention and GitHub blocks reopening a PR whose branch was force-pushed. Same branch, rebased onto the rewritten main.

Summary by CodeRabbit

• New Features

  • ServiceProvider annotation now supports optional parameters, with automatic contract inference when contracts are not explicitly specified.

• Improvements

  • Java runtime selection logic enhanced in build scripts for better version compatibility handling.

• Tests

  • Added test coverage for automatic service contract inference scenarios.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adds optional contract specification to @ServiceProvider annotations by inferring contracts from provider implementations, updates the annotation parameter to have a default empty value, implements BFS-based contract detection in the processor, and includes test validation. Build infrastructure is simplified by removing the foojay resolver plugin and enhancing Java runtime compatibility validation.

Changes

Service Contract Inference

Layer / File(s)	Summary
Annotation parameter default modules/annotations/src/main/kotlin/com/github/eventhorizonlab/spi/ServiceScheme.kt	ServiceProvider annotation's value vararg parameter now has a default empty array, enabling usage without explicit contract types.
Processor contract inference logic modules/processor/src/main/kotlin/com/github/eventhorizonlab/spi/ServiceSchemeProcessor.kt	When @ServiceProvider specifies no contracts, the processor infers @ServiceContract interfaces by traversing provider supertypes with a new inferContractsFromProvider helper using breadth-first search and cycle detection. Errors are emitted if no contracts are inferred; explicit contracts bypass inference.
Contract inference test cases modules/processor/src/test/kotlin/com/github/eventhorizonlab/spi/ServiceSchemeProcessorSpec.kt	Tests validate that a no-argument @ServiceProvider correctly infers a contract interface, and that compilation fails with proper diagnostics when no contracts can be inferred.

Build Infrastructure Updates

Layer / File(s)	Summary
Gradle wrapper Java runtime selection gradlew	Wrapper script now validates JAVA_HOME by parsing java -version, rejects versions >= 24, and falls back to discovering Java 21 from mise-managed installation directories if JAVA_HOME is unset.
Settings plugin removal settings.gradle	Foojay resolver convention plugin block is removed; project includes and root project naming remain unchanged.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

• feat(processor): allow @ServiceProvider without specifying the contract #6: This PR directly implements the requested feature—allowing @ServiceProvider without explicit contracts by adding the default empty vararg and implementing the inferContractsFromProvider mechanism.
• fix(processor): validate that providers implement their declared contract #17: Related to provider/contract handling enhancements in ServiceSchemeProcessor; this PR's contract inference complements future assignability validation logic.

Poem

🐰 A rabbit hops through types with grace,
Inferring contracts left and place—
No explicit bounds? No need to fear,
The processor sees what contracts are near!
whiskers twitch with build delight ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and accurately summarizes the main change: adding support for no-argument @ServiceProvider annotations through contract inference in the processor.
Description check	✅ Passed	The description covers key changes and lists affected modules, but lacks several template sections: Related Issues, detailed module checkboxes, versioning guidance, testing steps, and the reviewers notes are minimal.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@gradlew`:
- Around line 134-144: The current for-loop that sets JAVA_HOME only checks
mise-specific candidates and reduces portability; update the fallback logic
around the JAVA_HOME assignment loop to (1) include additional common install
locations (e.g., ~/.sdkman/candidates/java, ~/.asdf/installs/java, /usr/lib/jvm,
/Library/Java/JavaVirtualMachines, /opt/homebrew/opt/openjdk@21) and (2) if none
of those candidates match, attempt to resolve java on PATH (use command -v java
and follow symlinks to infer JAVA_HOME) before failing; modify the loop and the
block that assigns/export JAVA_HOME to search these extra candidate directories
and the PATH-resolve fallback, or alternatively add a clear README note
documenting the mise dependency if you prefer not to expand the search.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 50854f5c-7781-43ff-98fc-67f9626c9bc3

📥 Commits

Reviewing files that changed from the base of the PR and between fdc0ff3 and ed22e38.

📒 Files selected for processing (5)

• gradlew
• modules/annotations/src/main/kotlin/com/github/eventhorizonlab/spi/ServiceScheme.kt
• modules/processor/src/main/kotlin/com/github/eventhorizonlab/spi/ServiceSchemeProcessor.kt
• modules/processor/src/test/kotlin/com/github/eventhorizonlab/spi/ServiceSchemeProcessorSpec.kt
• settings.gradle

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚖️ Poor tradeoff

Hardcoded mise installation paths reduce portability.

The fallback logic searches only mise-specific paths (~/.local/share/mise/installs/java/), which will fail on systems using different Java version managers (SDKMAN, jEnv, asdf, Homebrew, system packages, etc.) or custom installation locations. Consider documenting this mise dependency or broadening the search to include other common Java installation paths.

📝 Potential paths to search across multiple version managers

# Additional common Java installation locations to consider:
# - SDKMAN: ~/.sdkman/candidates/java/
# - asdf: ~/.asdf/installs/java/
# - Homebrew (macOS): /opt/homebrew/opt/openjdk@21
# - System (Linux): /usr/lib/jvm/
# - System (macOS): /Library/Java/JavaVirtualMachines/

However, adding all these paths may increase complexity. An alternative is documenting the mise requirement in the project README.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@gradlew` around lines 134 - 144, The current for-loop that sets JAVA_HOME
only checks mise-specific candidates and reduces portability; update the
fallback logic around the JAVA_HOME assignment loop to (1) include additional
common install locations (e.g., ~/.sdkman/candidates/java,
~/.asdf/installs/java, /usr/lib/jvm, /Library/Java/JavaVirtualMachines,
/opt/homebrew/opt/openjdk@21) and (2) if none of those candidates match, attempt
to resolve java on PATH (use command -v java and follow symlinks to infer
JAVA_HOME) before failing; modify the loop and the block that assigns/export
JAVA_HOME to search these extra candidate directories and the PATH-resolve
fallback, or alternatively add a clear README note documenting the mise
dependency if you prefer not to expand the search.