InvMenu v3.0

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

InvMenu::sessionize() — Sessionized was an unnecessary feature which had the same effect as creating a cloned InvMenu instance for each player. If you'd still like to create sessionized InvMenu instances, you may use InvMenu::createSessionized() instead of InvMenu::create(). Sessionized InvMenu instances are just a cast over unsessionized ones from now onwards and will actually create a new InvMenu instance with copied properties (readonly, listeners etc).
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. The only reason behind these inventory classes were to define their network types which is no longer necessary in 4.0. All of these classes have been replaced by an invMenuInventory class.
HolderData — This has been replaced by a much better designed 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 was actually 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. It now accepts an optional second parameter which is an Inventory instance. (Please don't use this feature though, there are a few issues with garbage collection of InventoryChangeListener). This lets you create a menu out of ANY inventory and keeps the InvMenu synchronized with that Inventory. This only maintains synchronization. Modifying items in the InvMenu won't modify items in the 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 to do that. You no longer need to create classes for registering brewing and other inventories that aren't provided by InvMenu. It only takes one line now!
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. To create sessionized InvMenu instances, create InvMenu using InvMenu::createSessionized() instead of InvMenu::create().
BaseFakeInventory, SingleBlockInventory have been removed. In fact, all inventory classes have been removed. There only exists one now, and that is InvMenuInventory. There isn't necessarily any reason to create your own InvMenuInventory class anyway, now.
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 by calling InvMenuHandler::registerMenuType() where you'll need to pass a MenuMetadata object which contains a string identifier. That identifier can then be used in InvMenu::create().

Quick Start