Repoint PlaceholderAPI and bump ProtocolLib to resolvable versions

[dmccoystephenson]

Summary

The build could not resolve two dependencies, failing before any Kotlin compiled. Both were pinned when the project was last touched in 2024 and have since been removed from their repositories — this is external bit-rot, nothing in this repo changed.

PlaceholderAPI — needed two changes, not one:

• The repository URL repo.extendedclip.com/content/repositories/placeholderapi/ now 301s to repo.helpch.at/releases. Repointed to the redirect target.
• 2.11.2 is not published at that new location either (404), so the version had to move as well. Chose 2.11.7 — the lowest version still available — to keep API drift minimal rather than jumping to the current 2.12.3.

ProtocolLib — 5.0.0-SNAPSHOT has been purged; maven-metadata.xml now lists only 5.3.0 and 5.4.0-SNAPSHOT. Pinned 5.3.0, the current release, rather than another snapshot so the build no longer depends on a mutable version.

All four target artifacts were confirmed resolvable by direct probe (.pom and .jar, 200) before making the change.

Scope

10 files, 11 insertions, 11 deletions — one line each, plus the repo URL.

This sits exactly at the ~10-file soft ceiling and is a deliberate, stated exception: the change is dependency-coupled and cannot be split. PlaceholderAPI is declared in 9 modules and resolution fails on all of them; fixing a subset leaves the build red, and fixing PlaceholderAPI without ProtocolLib (or vice versa) also leaves it red. The two must land together to move the build past resolution at all.

Anchor verdict

UNVERIFIED locally — there is no JDK 17 on the development device, and Gradle 7.6 fails on both JDK 21 (Unsupported class file major version 65) and JDK 11, so ./gradlew cannot produce a signal there by any route. CI is the anchor, and its run on this PR is the real verdict. I'll report it here.

Known risk

These are not cosmetic bumps. 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 — that work was invisible until resolution succeeded and the compiler could actually run. If CI now fails at the compile step rather than at resolution, that is progress, not regression, and the remaining breakage will be fixed here or filed separately depending on its size.

Test plan

• me.clip:placeholderapi:2.11.7 .pom and .jar return 200 at repo.helpch.at/releases
• com.comphenix.protocol:ProtocolLib:5.3.0 .pom and .jar return 200 at repo.dmulloy2.net
• No stale 2.11.2, 5.0.0-SNAPSHOT, or extendedclip reference remains in any build.gradle
• repo.properties untouched
• CI gets past dependency resolution — confirmed: failure moved from resolution to compileKotlin, 119 tasks executed, 70 of 71 modules compile (run 31342495454)
• Remaining single compile error diagnosed and mirrored to Fix "Overload resolution ambiguity" compiling rpk-characters-bukkit #5 rather than guessed at

Do-not-auto-merge

Modifies build.gradle and **/build.gradle, both on the do-not-auto-merge list — dependency changes across a 71-module tree. Left for human review.

Closes #3

[dmccoystephenson]

Self-review rubric:

• Scope: PASS — git diff --name-only origin/main...HEAD returns exactly the 10 build.gradle files needed; 11 insertions, 11 deletions, one line each plus the repository URL. No incidental edits.
• Issue resolution: PASS, with a stated split — Build fails: PlaceholderAPI 2.11.2 and ProtocolLib 5.0.0-SNAPSHOT no longer resolve #3 as titled (dependency resolution) is resolved and verified by CI. Its final criterion about API breakage has been split out to Fix "Overload resolution ambiguity" compiling rpk-characters-bukkit #5 rather than quietly dropped; see the comment on Build fails: PlaceholderAPI 2.11.2 and ProtocolLib 5.0.0-SNAPSHOT no longer resolve #3. Flagging this rather than letting Closes #3 imply more than the PR delivers.
• Docs: PASS — no documentation source names these versions; README.md does not exist yet, and no config.yml or plugin.yml key references them.
• No credential churn: PASS — repo.properties is not in the diff.
• Sibling structure: PASS — every edited declaration keeps the existing implementation group: … name: … version: … form; only the version literal changed.
• Correct module of the lib/impl pair: PASS — all 10 files are the modules that actually declare the dependency, enumerated by grep -rln rather than assumed. No *-lib-bukkit module declares either artifact.
• Tests-new / Tests-fix: not applicable — no behavioural code changed; this is dependency coordinates only. There is no unit test that can assert "an artifact resolves"; the build either resolves it or does not, and CI is the direct evidence.
• License header / Permission declared / Result type / Service resolution / Main-thread I/O / Messages externalized: not applicable — no Kotlin source, commands, or permissions touched.
• Fidelity to upstream: not applicable to this PR — Build fails: PlaceholderAPI 2.11.2 and ProtocolLib 5.0.0-SNAPSHOT no longer resolve #3 is fork-native. It became relevant downstream: the compile error this PR exposed maps to upstream Fix "Overload resolution ambiguity" error occurring upon compiling rpk-characters-bukkit module RP-Kit/RPKit#666, and I mirrored it to Fix "Overload resolution ambiguity" compiling rpk-characters-bukkit #5 recording the maintainer's decision verbatim rather than acting on my own reading.
• CI: FAIL — red, but at a different and later stage than before.

On the CI FAIL — this is the progress the PR was aiming for.

	Before (PR #2, run 31341624637)	After (this PR, run 31342495454)
Failure stage	dependency resolution	compileKotlin
Duration	1m 07s	1m 57s
Modules compiled	0	70 of 71
Gradle tasks executed	—	119

The build now gets all the way to the compiler and every module except rpk-characters-bukkit compiles cleanly. The single remaining error is:

e: .../rpk-characters-bukkit/src/main/kotlin/com/rpkit/characters/bukkit/protocol/Protocol.kt: (77, 26): Overload resolution ambiguity

ProtocolLib 5.3.0 exposes two 7-argument PlayerInfoData constructors differing only in the final parameter's type, and Protocol.kt:77 passes a bare null, which matches both.

I did not fix it in this PR, deliberately. It is a pre-existing defect that upstream already tracks as RP-Kit#666, the project owner has stated a scope decision on it ("gut the nameplate functionality"), and there is an open upstream PR implementing that. Choosing between removing the feature and disambiguating the call is a product decision with runtime implications on a code path that cannot be exercised without a live Minecraft server. Mirrored to #5 with both options recorded and neither selected.

Recommendation: merge this to bank the resolution fix — it is independently correct and unblocks every other module — then take #5 once the nameplate question is decided.