Methods are now properly annotated @Nullable when they may return null. More descriptive exceptions are thrown when issues occur instead of just returning null.
Going forward, the primary file uploaded to Bukkit will probably be the smaller build made with the `recent` profile, supporting only the last 2 versions. The uberjar created by the `all` will be provided as an additional download. OpenInv v3.1.3-SNAPSHOT `all` uberjar currently is 276KB. The `recent` jar is only 81KB. It's getting silly, and will only continue to get worse.
repo.bukkit.org is dead, Spigot doesn't host builds that old. Didn't realize that I'd installed it locally when compiling CB 1.4.5 to use with OpenInv. Whoops.
Corrected dependency order - no idea why this compiled at all before. My bad.
This allows API users to prevent issues caused by multiple different copies of the Player being loaded, such as #49. Multiple instances of the same player could be obtained by calling IOpenInv#loadPlayer, waiting for OpenInv to remove it from the cache, then calling the method again.
The project was very messy and due to older Bukkit packaging conventions, 1_4_5 and 1_4_6 were sorted away from the rest of the versioned code. All of the versioned internals are now submodules of the internal module.
Rather than use the hackish existing method of abusing the shade plugin to combine "dependencies" for a dummy assembly project, we're actually using the assembly plugin.
Profiles are still split up between the parent pom and the internal module pom, but they're much more clean.
The API is now its own module and can be compiled and released as a separate file for developers. Soon, Bukkit ticket 20, you'll be closed.
This is pretty messy, but I can't think of a better way to avoid saving about 5 times in a row. Then again, I did just wake up, so my brain may not be on point yet.
You could argue that ShadowRanger's conversion of everything to UUID is better, but that would result in us having to contact Mojang's servers simply to fetch a player by UUID for versions < 1.7.5. It seems excessive (not to mention that uncached contact can result in rate limiting) when the server itself will not remember who they are across name changes. If they can re-obtain everything in their inventory, they can re-run /ac.