Skip to content

Make the API self-contained again - #10

Merged
rubensworks merged 2 commits into
master-26from
claude/minecraft-26-3-update-xr1cny
Sep 20, 2026
Merged

rubensworks merged 2 commits into
master-26from
claude/minecraft-26-3-update-xr1cny

Conversation

@rubensworks

Copy link
Copy Markdown
Member

CyclopsCore consumes this repo as a submodule in a dedicated api source set whose compile classpath is deliberately restricted to Minecraft, NeoForge and CyclopsCore's loader-common. It explicitly does not see CyclopsCore's loader-neoforge main sources, and of course not the CommonCapabilities mod.

Two references had drifted in that violate that. They compile fine inside CommonCapabilities (where this repo sits inside src/main/java), which is why they went unnoticed, but they make :loader-neoforge:compileApiJava fail in CyclopsCore. That is what currently blocks CyclopsCore from tracking the latest master-26.

Changes

ItemMatch.DATA_COMPARATOR was typed as the mod's own org.cyclops.commoncapabilities.ingredient.DataComparator. It only uses two methods, so those are extracted into a new org.cyclops.commoncapabilities.api.ingredient.IDataComparator and the field is retyped to that. DataComparator in the mod implements the new interface (CyclopsMC/CommonCapabilities#50).

RecipeDefinition.fromRecipeId used IModHelpersNeoForge. Both IModHelpers.get() and IModHelpersNeoForge.get() return the exact same CyclopsCoreInstance.MOD.getModHelpers() singleton, and getMinecraftClientHelpers() / getRecipes() are already declared on the common interfaces, so dropping the loader-specific subinterface is behaviour-neutral.

Guard against regressions

.github/check-self-contained.sh resolves every org.cyclops reference in this repo (imports and inline fully-qualified usages) and fails when one points at the CommonCapabilities mod, or at a CyclopsCore class that does not exist under loader-common/src/main/java. It is wired up in a new CI workflow that checks out CyclopsCore alongside this repo.

A package-level allowlist would not have been enough here: IModHelpersNeoForge lives in the same org.cyclops.cyclopscore.helper package as the perfectly legal IModHelpers. Resolving against CyclopsCore's actual loader-common tree encodes the real invariant instead.

Verified that the check fails on the current master-26 tree with exactly those two findings, and passes on this branch.

Validation

  • :loader-neoforge:compileApiJava in CyclopsCore with the submodule moved here: passes
  • CyclopsCore build + runGameTestServer: green
  • CommonCapabilities build + runGameTestServer: green

🤖 Generated with Claude Code

https://claude.ai/code/session_01V35MFZ7JSgoLe79J4d1uxf


Generated by Claude Code

CyclopsCore compiles this API in a dedicated source set that only sees
Minecraft, NeoForge and CyclopsCore's loader-common. Two references had
crept in that break that build:

- ItemMatch referenced the CommonCapabilities mod's own DataComparator.
  It only needs two methods, so those are extracted into a new
  IDataComparator interface that the mod's class can implement.
- RecipeDefinition used IModHelpersNeoForge. IModHelpers resolves to the
  exact same singleton and already declares getMinecraftClientHelpers(),
  so the loader-specific subinterface is unnecessary.

Adds .github/check-self-contained.sh, run from CI, which resolves every
org.cyclops reference in this repo and fails when it points at the
CommonCapabilities mod or at a CyclopsCore class outside loader-common.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V35MFZ7JSgoLe79J4d1uxf
rubensworks added a commit to CyclopsMC/CyclopsCore that referenced this pull request Sep 20, 2026
The previous master-26 tip referenced the CommonCapabilities mod's
DataComparator and CyclopsCore's own IModHelpersNeoForge, neither of
which is on the api source set's compile classpath. Both are resolved in
CyclopsMC/CommonCapabilitiesAPI#10.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V35MFZ7JSgoLe79J4d1uxf
CI checks CyclopsCore out into a subdirectory, which the recursive grep
picked up, reporting all of its loader-specific classes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V35MFZ7JSgoLe79J4d1uxf
@rubensworks
rubensworks merged commit eac103d into master-26 Sep 20, 2026
3 checks passed
@rubensworks
rubensworks deleted the claude/minecraft-26-3-update-xr1cny branch September 20, 2026 10:49
rubensworks added a commit to CyclopsMC/CyclopsCore that referenced this pull request Sep 20, 2026
CyclopsMC/CommonCapabilitiesAPI#10 was squash-merged, so the branch this
pointed at is gone. The tree is identical.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V35MFZ7JSgoLe79J4d1uxf
rubensworks added a commit to CyclopsMC/CommonCapabilities that referenced this pull request Sep 20, 2026
CyclopsMC/CommonCapabilitiesAPI#10 was squash-merged, so the branch this
pointed at is gone. The tree is identical.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V35MFZ7JSgoLe79J4d1uxf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant