InvMenu v3.0

InvMenu v3.0 is a major rewrite of InvMenu v2.0!

InvMenu::createSessionized() — Sessionize relied on unsessionized InvMenus and only redirected method calls. What sessionized does can be accomplished by using multiple InvMenu instances. It was quite literally multiple InvMenu instances hacked together into one.

InvMenu::getListener() — There was no reason to expose the listener.
InvMenu::getInventoryCloseListener() — Again, no reason to expose the listener.

BaseFakeInventory, ChestInventory, DoubleChestInventory, HopperInventory, SingleBlockInventory — These are no longer needed. BaseFakeInventory was infact a poorly-written class with a few player-related property handlers in it (basically, a part of the API lied in the inventory class). The only reason behind these inventory classes were to define their network types which is no longer necessary due to the change in pattern to register new InvMenu types. All of these classes have been replaced by a single invMenuInventory class.
HolderData — This has been replaced by a much better written PlayerSession class.
DelayedFakeBlockDataNotifyTask — The whole reason behind having this was to work-around the issue of sending double chest inventories to the client. The client would take time to render the "pairing" and this task assumed the pairing took up to 5 ticks (which actually was a really bad estimation). This issue has been solved by handling NetworkStackLatencyPacket (thanks dktapps).

InvMenu::create()'s first parameter is no longer path to an inventory class. The first parameter has been changed to a registered MenuMetadata identifier (string). On the API 4.0 branch, it now accepts an optional second parameter which is an Inventory instance. This lets you create a menu out of ANY inventory and keeps the InvMenu's inventory and Inventory synchronized with each other (pretty much creating a menu by wrapping an inventory).
InvMenu::__construct() now accepts only one parameter — MenuMetadata.
InvMenuHandler::registerMenuType(MenuMetadata $type) is the new way to create custom inventory instances. See InvMenuHandler::registerDefaultMenuTypes() to find out how that's done. You no longer need to create classes for registering brewing and other inventories that aren't provided by InvMenu. It can be achieved in a single line!
PlayerManager::get($player)->getCurrentMenu() — A utility method to get the InvMenu instance of the InvMenu instance linked with the inventory the player is currently viewing. Returns InvMenu|null.

InvMenu::sessionize() has been removed and is replaced by a deprecated InvMenu::createSessionize() method (will be removed in an upcoming version). It's recommended you call InvMenu::create() multiple times instead.
BaseFakeInventory and SingleBlockInventory have been removed. In fact, all inventory classes have been removed. There only exists one now, and that is InvMenuInventory (don't see any scenarios where anyone would want to extend this class though, might make it final in the future).
InvMenu::create()'s first parameter is no longer path to an inventory class extending BaseFakeInventory. It has been replaced by a registered MenuMetadata identifier. If you want to create a brewing inventory, you need to register it (desirably on plugin startup (onLoad()/onEnable())) by calling InvMenuHandler::registerMenuType() where you'll be required to pass a MenuMetadata object containing a string identifier. That identifier can then be passed to InvMenu::create() to create that type of menu.

Quick Start