Refuse to enable when Set Homes v1 is installed alongside

[milanmalhotra]

Part of #41.

With both jars in plugins/, Bukkit loads both plugins happily and the command set splits along a line no player can see. Measured twice on Paper 1.21.4 on 2026-08-16 with the real SetHomes-1.3.0.jar; full results in #41 (comment).

Command	Goes to	Why
/sethome, /home, /delhome, /uhome, /home-of, /setmax	v1	v1 declares them as primary names; we declare them only as aliases of create-home, go-home, delete-home, move-home, go-player-home, set-max-homes
/homes, /blacklist	v2	both declare them as primaries, so first registration wins
/list-homes, /create-home	v2	ours only

SimpleCommandMap.register lets a primary name displace an existing alias, but never lets an alias displace anything. Every name we lose is one where v1 holds the primary and we hold the alias, so v1 takes them regardless of load order. Set Homes Two loaded first in both test runs and still lost all six. Renaming jars or reordering loads cannot change this.

The result is split storage. /sethome shop writes to v1's homes.yml, /homes opens our menu without it, and the admin who has already run the import believes the migration is complete. The server logs nothing about the clash, in either boot, so nobody finds this state except from player reports.

What to build

As the first statement of onEnable, before any directory is created or any config is written: if a plugin named exactly SetHomes is loaded, log a severe block and disable ourselves.

Nothing of v1's is touched and the server keeps running v1 exactly as it did the day before. The block names the jar to move out of plugins/, says to keep it rather than delete it so a rollback stays possible, and gives /import-homes sethomes as the step to run once it is gone.

A warning that can be ignored is not enough here. Ignoring it costs players their homes, while refusing to start costs a restart.

Notes

• Exact name match only. SetHomesThree and a lowercase sethomes must both enable normally.
• Do not offer /sethomestwo:sethome in the block as a stopgap. It reaches us today only because we are enabled; under a refusal there is no namespaced form to fall back to.
• The alternatives are recorded in Consolidate onto the Set Homes listing: publish v2 as the v1 upgrade #41 and were rejected: disabling or unloading v1 from our onEnable, moving v1's jar ourselves, and winning the names deterministically with primary declarations plus loadbefore.
• Risk to check early: MockBukkit may not allow registering a second plugin under an arbitrary name. If it does not, extract the guard to a testable predicate, unit test that, and verify the wiring on the local Paper server instead.

Acceptance criteria

• A plugin named exactly SetHomes being loaded leaves Set Homes Two disabled, with a severe log block naming the file to move, where to keep it, and the command to run afterwards.
• The refusal triggers on SetHomes and on nothing else.
• The guard runs before createDirectories() and initConfig(), so a refused boot creates nothing on disk.
• Nothing under plugins/SetHomes/ is read, written, renamed or deleted on a refused boot.
• The README describes the refusal and what to do about it.

[milanmalhotra]

Merged to dev in c3c76f9 (PR #58). Verified in game on Paper 1.21.4 against the real SetHomes 1.3.0 jar, both directions: with v1 present we refuse and it keeps running, with v1 removed we enable normally.