Build fails: PlaceholderAPI 2.11.2 and ProtocolLib 5.0.0-SNAPSHOT no longer resolve

[dmccoystephenson]

Context

Discovered by the first CI run (PR #2, run 31341624637). The build fails at dependency resolution, before any Kotlin is compiled:

> Could not find me.clip:placeholderapi:2.11.2.
> Could not find com.comphenix.protocol:ProtocolLib:5.0.0-SNAPSHOT.
    Required by: project :bukkit:rpk-characters-bukkit

This is upstream bit-rot, not a regression in this fork — both artifacts were pinned when the project was last touched in 2024 and have since been removed from their repositories. Nothing in this repo changed.

Both must be fixed together: fixing either one alone leaves resolution failing on the other.

Finding 1 — PlaceholderAPI: repo moved and 2.11.2 was dropped

The repository URL in the root build.gradle subprojects block is stale:

maven { url "https://repo.extendedclip.com/content/repositories/placeholderapi/" }

Verified by probe:

URL	Result
repo.extendedclip.com/content/repositories/placeholderapi/.../2.11.2.pom	301 → redirects to repo.helpch.at/releases/...
repo.helpch.at/releases/me/clip/placeholderapi/2.11.2/placeholderapi-2.11.2.pom	404 — 2.11.2 no longer published

Versions currently available at repo.helpch.at/releases: 2.11.7, 2.12.0, 2.12.1, 2.12.2, 2.12.3.

So this needs both a repo URL change and a version bump — the pinned version does not exist at the new location.

Affected modules (9) — all declare me.clip:placeholderapi:2.11.2:

rpk-characters-bukkit, rpk-chat-bukkit, rpk-classes-bukkit, rpk-economy-bukkit, rpk-experience-bukkit, rpk-permissions-bukkit, rpk-players-bukkit, rpk-professions-bukkit, rpk-stats-bukkit

Finding 2 — ProtocolLib: 5.0.0-SNAPSHOT purged

repo.dmulloy2.net is alive (200 at the repo root), but its maven-metadata.xml for com.comphenix.protocol:ProtocolLib now lists only:

<latest>5.4.0-SNAPSHOT</latest>
<release>5.3.0</release>
<versions>
  <version>5.3.0</version>
  <version>5.4.0-SNAPSHOT</version>
</versions>

5.0.0-SNAPSHOT is gone. 5.3.0 confirmed resolvable (200 on its .pom).

Affected module (1): rpk-characters-bukkit

Acceptance criteria

• The PlaceholderAPI repository URL points at a location that actually serves the artifact
• The pinned PlaceholderAPI version is one that exists at that location
• The pinned ProtocolLib version is one that exists (5.3.0 is the current release)
• ./gradlew compileKotlin gets past dependency resolution in CI
• Any API breakage introduced by the version bumps is fixed, not suppressed

Assumptions and open questions

• The version bumps are not cosmetic. PlaceholderAPI 2.11.2 → 2.11.7+ and ProtocolLib 5.0.0-SNAPSHOT → 5.3.0 may carry API changes that break compilation in the modules that use them. The size of that follow-on work is unknown until resolution succeeds and the compiler actually runs — this issue may uncover more work behind it.
• Which PlaceholderAPI version to target is a judgment call and is deliberately left open: 2.11.7 is the smallest move off the current pin, 2.12.3 is current. Whoever picks should weigh API drift against staying supported.
• repo.extendedclip.com/releases/ also still serves some artifacts (2.11.6 probed 200), so there may be more than one valid repo choice. repo.helpch.at/releases is where the old URL actually redirects.

Out of scope

• The CI workflow itself (PR Add CI: Gradle build workflow pinned to JDK 17 #2) — the workflow is working correctly; surfacing this failure is what it is for.

[dmccoystephenson]

Splitting the last acceptance criterion out to #5.

This issue's final criterion — "Any API breakage introduced by the version bumps is fixed, not suppressed" — was written when the breakage behind resolution was still invisible. CI on PR #4 has now revealed it, and it is narrower and more specific than anticipated: exactly one compile error, in one file, and it is a pre-existing defect upstream already knows about (RP-Kit#666) with a maintainer scope decision attached and an open upstream PR implementing it.

Flagging the split explicitly rather than editing it away: the remaining work is tracked as #5, not dropped. Resolving it requires a human product decision (remove the nameplate feature per the maintainer's direction, versus disambiguate the call and keep it), which is not something this loop should settle on its own.

What PR #4 does close is this issue as titled — dependency resolution. Verified by CI run 31342495454: resolution now succeeds, 119 Gradle tasks execute, and 70 of 71 modules compile. The build no longer fails before reaching the compiler.