Skip to content

Pin MockBukkit to v4.110.0 (fix flaky SNAPSHOT resolution)#2981

Merged
tastybento merged 1 commit into
developfrom
ci/pin-mockbukkit-version
May 19, 2026
Merged

Pin MockBukkit to v4.110.0 (fix flaky SNAPSHOT resolution)#2981
tastybento merged 1 commit into
developfrom
ci/pin-mockbukkit-version

Conversation

@tastybento
Copy link
Copy Markdown
Member

Problem

develop currently can't compile tests on a clean CI runner:

Could not find MockBukkit-v1.21-SNAPSHOT.jar
  (com.github.MockBukkit:MockBukkit:v1.21-SNAPSHOT:v4.110.0-g1a072c3-1)

Direct probing of JitPack:

$ curl -sIL https://jitpack.io/com/github/MockBukkit/MockBukkit/v1.21-SNAPSHOT/MockBukkit-v1.21-v4.110.0-g1a072c3-1.jar
HTTP/2 200          ← jar exists
$ curl -sIL https://jitpack.io/com/github/MockBukkit/MockBukkit/v1.21-SNAPSHOT/MockBukkit-v1.21-v4.110.0-g1a072c3-1.pom
HTTP/2 404          ← but the POM doesn't

JitPack's maven-metadata.xml advertises the timestamped version, the jar is reachable, but the corresponding POM 404s. Gradle requires the POM for dependency resolution, so the build aborts.

Triggering a JitPack rebuild for a newer tag (e.g. v4.113.1) also fails — MockBukkit recently moved to a Java 25 toolchain and JitPack's default build image only has Java 21:

Cannot find a Java installation on your machine (Linux amd64) matching:
  {languageVersion=25, vendor=any vendor, …}
Toolchain download repositories have not been configured.

Fix

Pin to the most recent tag that's actually serving on JitPack: v4.110.0 (May 5 2026). Both .pom and .jar return 200, and this is the version the SNAPSHOT pointer was already trying to resolve to under the covers.

The pin trades the (mostly notional) benefit of automatic snapshot updates for build stability. When JitPack starts publishing newer tags successfully — or when this project moves off JitPack — we can bump.

Also: testSetRange update

IslandTest.testSetRange was asserting that island.setRange(200) succeeded when the configured distance was 100 — which is exactly the corruption pattern Island.setRange now refuses (introduced in #2980). Updated the test to simulate an addon that opts out of equal-range enforcement (isEnforceEqualRanges() == false), which is the legitimate use case (claim resizing in StrangerRealms-style addons). The new testSetRange* tests added in #2980 cover the enforce-true and unregistered-world paths.

Test plan

  • ./gradlew compileTestJava --refresh-dependencies — clean
  • ./gradlew test — full suite green
  • ./gradlew test --tests "world.bentobox.bentobox.database.objects.IslandTest" — green

🤖 Generated with Claude Code

JitPack's v1.21-SNAPSHOT pointer for MockBukkit is unreliable: its
maven-metadata.xml currently advertises version v1.21-v4.110.0-g1a072c3-1
but the corresponding .pom 404s, so Gradle aborts dependency resolution
mid-build. Newer MockBukkit tags (>= v4.111) cannot be auto-built on
JitPack either, because the project moved to a Java 25 toolchain that
JitPack's default image lacks. v4.110.0 is the most recent tag with
both .pom and .jar available on JitPack, and is the version the
SNAPSHOT pointer was already trying to resolve to.

Also update IslandTest.testSetRange — it was previously asserting that
setRange(200) succeeded when the configured distance was 100, which is
exactly the corruption pattern Island.setRange now refuses. Switch the
test to simulate an addon that opts out via isEnforceEqualRanges()==false
(the legitimate use case, e.g. StrangerRealms claim resizing), which is
what setRange is actually for after the hardening.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@tastybento tastybento merged commit d65ca2a into develop May 19, 2026
1 check passed
@sonarqubecloud
Copy link
Copy Markdown

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