Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Comparing changes

Choose two branches to see what's changed or to start a new pull request. If you need to, you can also compare across forks.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also compare across forks.
base fork: Bukkit/Bukkit
base: master
head fork: stephank/Bukkit
compare: plugin-refac
Checking mergeability… Don't worry, you can still create the pull request.
Commits on Feb 25, 2011
@stephank stephank Rename PluginDescriptionFile to PluginDescription.
PluginDescription will contain all metadata, including data
not contained in the YAML file.
@stephank stephank Move YAML parsing to a PluginDescription subclass.
Plugin interfaces may have other, more intuitive means of getting
metadata for plugins in the target language.

Because Commands are integral part of Bukkit, there's no need to
separate the regular YAML parsing and command parsing in classes.
A separate method will do.
@stephank stephank Allow extending of YAML description format.
loadMap and saveMap are now protected and thus overridable.

saveMap takes an existing Map object it can simply add to, rather
than creating one itself. This makes more sense when overriding.
@stephank stephank Move Java stuff to JavaPluginDescription. c42de72
@stephank stephank Removing unused Reader-based constructors. ca3592d
@stephank stephank Move conventions out of Plugin, into Description.
These are getFile, getDataFolder, getConfiguration. Avoids code
duplification in new plugin interfaces.

The JavaPlugin constructor is also simplified much, because these
parameters are now accessible through the Description object.
@stephank stephank Move loader ref from Plugin to Description. e2e4a29
@stephank stephank Move the ClassLoader to JavaPluginDescription.
The PluginClassLoader is lazily instantiated.
@stephank stephank onEnable/onDisable are specific to Java plugins. 6952686
@stephank stephank Move CommandMap instance to PluginManager.
Tying Commands more tightly with plugins will allow for proper
clean up after unloading a plugin.
@stephank stephank Expose the CommandMap instance. 45bd23a
@stephank stephank The loader is responsible for installing Commands. e16f217
@stephank stephank Separate Java-specifics from PluginCommand.
In order to pull this off, YamlPluginDescription needs to know which
class to instantiate. Therefor, an abstract factory method was added.
@stephank stephank Small style fix.
RegisterInterface -> registerInterface
@stephank stephank Remove the separate plugin loading step.
A loaded plugin is enabled, and an enabled plugin is loaded.

The problem of lingering Plugin instances will be solved with
dependency management.
@stephank stephank Make Java plugins a Bukkit default.
As opposed to a CraftBukkit default.
@stephank stephank Let PluginManager manage the plugin folder. f790097
@stephank stephank Separate reading of the plugin description. c0f7897
@stephank stephank Fixing some annoying warnings. a24100d
@stephank stephank Use static Logger variables everywhere. 30fd390
@stephank stephank Merge manager's lookupNames and plugins variables. c02dbf8
@stephank stephank Build an index of PluginDescriptions.
This way, there's a structure to build dependency management on
top off.
@stephank stephank Add per-loader indexing of plugins.
This allows newly registered loaders to add newly available plugins
to the index, rather than reindexing everything.

To accomplish this, indexing is now primarily based on loaders,
rather than filters.
@stephank stephank Fold PluginCommand into Command.
The bulk of commands will be associated with a plugin. For the rest,
we can afford setting the owner to null. Keeping this separate adds
little extra value.
@stephank stephank Small refactor of PluginManager interface.
Rename and move some methods, to hopefully make clearer the workings
and which functionality is related.

Remove clearPlugins, of which everything should be handled by
@stephank stephank Clean up a plugin's commands when disabled. ffaa109
@stephank stephank Clean up a plugin's listeners when disabled. 1b26767
@stephank stephank Plugins can be enabled only once.
This used to be the case, but had to be reimplemented.
@stephank stephank The manager sees to firing PLUGIN_* events.
Not the JavaPluginLoader.
@stephank stephank Properly clean up the plugin ref in the manager. 702b596
@stephank stephank Return loader instance from registerInterface. 0661cc5
@stephank stephank Option to load plugins using the system loader. c650842
@stephank stephank Pass the actual JavaPluginDescription to plugins.
Can be more specific than just PluginDescription here.
@stephank stephank Getting Fillr to compile again. UNTESTED
Watch me pummel this code into submission. An interesting side-effect
is that a lot of the JAR-specific code is gone.
@stephank stephank JavaDoc and minor style updates. 8e94012
@stephank stephank Add dependencies field for plugins. d0e04c7
@stephank stephank Plugin collection may be altered during iteration. 1401580
@stephank stephank First shot at some simple dependency handling.
Some limitations apply. FIXMEs are left where appropriate.
@stephank stephank registerInterface just takes a loader instance. 4be7c9c
@stephank stephank Reverse roles of manager and loader in discovery.
The PluginLoader is now itself responsible for iterating a plugin
directory, because we're keeping different loaders' plugins in
subdirectories. (The data directory of the loader's plugin.)

The JavaPluginLoader is the only exception, which still reads from
the main plugin directory.

This also neatly tucks away system plugin functionality, which is
Java-specific, in the JavaPluginLoader.
@stephank stephank Store Plugin instances in the dependency graph.
We'll use these later.
@stephank stephank Refine what plugins we index, and how we do it.
We need to reference plugins available on the filesystem by name,
of course. But we also need to properly clean up already enabled
plugins, which we reference by their PluginDescription.

The gist here is that clear() keeps enabled plugins in the graph,
but we don't keep them around in the name-index. If the plugin is
still available, it is expected to be re-inserted.
@stephank stephank PluginDependencyGraph#contains is no longer used. 5ffec28
@stephank stephank Keep things tidy: use proper visibility and accessors. 3362c1c
@stephank stephank Immediately ask loaders to discover plugins. cfc0399
@stephank stephank Clean up loaders when disabling a plugin. 447dd4c
@stephank stephank Add implicit plugin dependency on the loader. 13f6664
@stephank stephank Don't crash in #get when a plugin doesn't exist. 69c58cd
@stephank stephank Add commands to enable/disable plugins. 114516c
@stephank stephank Forgot to update dependents field of a loader's node. 0762e50
@stephank stephank Properly clear state on all nodes. 2a7f9f4
@stephank stephank More intelligent #enableAllPlugins().
As a side effect, moved all Visitor implementors from anonymous
classes into inner classes with a single instance.
@stephank stephank Small boo-boo in cleaning up dependents. 6a35a17
@stephank stephank Clear the ClassLoader on plugin unload. 593fd02
@stephank stephank Match up inserts and removes from class cache. 81ee924
@stephank stephank No reason for readSystemPluginDescription to be public. eccd8e0
@stephank stephank Allow plugins to reference others' classes.
This was already partially the case, but only for classes that the
other plugin had already loaded by itself. Loading new classes from
another plugin's package resulted in an error.

This does away with the cache completely, and relies on
ClassLoader built-in cache.
@stephank stephank Move listener invocation to JavaPlugin.
The way an event-handler is invoked is a plugin-interface-specific
thing. Languages other than Java can deal directly with method names
or references, for example, and only need the Event object.

A new JavaPlugin#registerEvent helper is available to make simplify
the call for Java plugin authors, and make the PluginManager more
agnostic to interface-specifics.
@stephank stephank More carefully deal with plugin exceptions. 4b15a72
@stephank stephank No longer need to check for JavaPlugin. 8e20c6f
@stephank stephank Allow plugins to inhibit (un)loading. db94ded
@stephank stephank Ditch legacy JavaPlugin constructor.
It has changed any way.
@stephank stephank Reduce one curft in JavaPlugin.
createExecutor can be a static method.

The server and description fields can have package visibility.
@stephank stephank Move usage formatting to the Command class.
This logic should be the same for all kinds of plugins.