- python plugins were loaded at a different time than java plugins; on initialization, reloaded all already-loaded plugins (meaning all java plugins); could be initialized twice (not important with SimplePluginManager, but since it's not true of bukkit-internal initialization, is not acceptable)
- dependency loading only attempts to work for other python plugins - completely ignores java plugins; however, does not work for python plugins, as it does not add python plugins to the map it checks: python plugins with dependencies will cause an infinite loop on startup!
- errors while a plugin is initializing will result in an uninitialized plugin being loaded into bukkit
- backslashes and python string special characters in the plugin's file name will result in an error while loading the plugin, due to altering the pythonpath via interp.exec()
- the data folder is added to the pythonpath - all plugin code should be /inside/ the plugin
- a single PythonInterpreter is used for all plugins, which means they share the same globals - all kinds of havoc, hard-to-pin-down errors, plugin-to-plugin sabotage, and other fun can come of this
- entirely copies JavaPluginLoader's eventexecutor creation - which means it will have to be updated each time an event is added!
- moved initialization to occur as soon as PluginLoader is instantiated - ie, very early; check if initialization has occured before
- keep a proper list of loaded python plugins; also check java plugin list
- throw an InvalidPluginException any time the plugin loader has an error
- manipulate PySystemState path directly (PySystemState is the implementation of the sys module)
- don't add the data directory to the pythonpath - may break compatibility with a (very) few plugins
- create a new PythonInterpreter for each plugin - tests show that this causes no significant speed loss
- use reflection to call the existing java loader's eventexecutor creation
:>