Commits on Feb 25, 2011
  1. Move usage formatting to the Command class.

    This logic should be the same for all kinds of plugins.
    committed Feb 25, 2011
  2. Reduce one curft in JavaPlugin.

    createExecutor can be a static method.
    The server and description fields can have package visibility.
    committed Feb 25, 2011
  3. Ditch legacy JavaPlugin constructor.

    It has changed any way.
    committed Feb 25, 2011
  4. 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.
    committed Feb 15, 2011
  5. 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.
    committed Feb 15, 2011
  6. More intelligent #enableAllPlugins().

    As a side effect, moved all Visitor implementors from anonymous
    classes into inner classes with a single instance.
    committed Feb 11, 2011
  7. 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.
    committed Feb 11, 2011
  8. Store Plugin instances in the dependency graph.

    We'll use these later.
    committed Feb 11, 2011
  9. 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.
    committed Feb 11, 2011
  10. First shot at some simple dependency handling.

    Some limitations apply. FIXMEs are left where appropriate.
    committed Feb 9, 2011
  11. 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.
    committed Feb 6, 2011
  12. Pass the actual JavaPluginDescription to plugins.

    Can be more specific than just PluginDescription here.
    committed Feb 6, 2011