I'd like to seek some ideas for a plugin engine which I have almost completed.
The objective of the engine is to be very generic, enough so that it could
be used for any type of application. Thus far, I have met that objective,
but I am having some issues deciding how plugin versioning and dependencies
should be handled. I would appreciate feedback on what I have so far, and
ideas for what might be an approach to take.

Without going into extreme detail, my engine thus far handles multiple versions
of the same plugin, each plugin can be dependent on multiple other plugins.
At startup time, the engine resolves all dependencies and makes available
an interface passed to every plugin that allows them to get ahold of any
Service that they depend on. Service is an interface plugins implement that
simply has create(), start() and stop() methods to let a plugin know when
it has been created, when it is now available, and when it is stopped. I
will probably add unload and reload as well, so that a plugin can handle
issues like saving state, and so forth when a plugin is to be unloaded or
reloaded at runtime. In the case it is unloaded or reloaded at runtime, all
dependent Services are notified that a plugin they depend on is about to
be unloaded or reloaded. If the plugin is to be unloaded, every dependent
plugin has the option of also being unloaded if they are coded in such a
way that they will not function without the dependency. During a reload,
each dependent plugin should be "paused" until it restablishes its reference
to the plugin it depends on. The engine would handle most of this.

Every plugin has their own PluginClassLoader instance. This allows for any
plugin to be unloaded or reloaded relatively easily at runtime.

Plugins are loaded by first parsing the plugin-conf.xml config file (to pick
up on any dependencies), then all class loader instances are created. Then
all plugins dependencies are resolved. Next all plugins create() methods
are called. At this point ALL plugins have now been instantiated and ready
to be used. Finally, the engine calls all plugins start() methods, so that
they may refer to dependent plugins, do whatever they need. When a plugin
is to be unloaded, or the engine is shutting down, their stop() method is

My dilema right now is, do I pass an instance of the plugin engine interface
and allow plugins in the start() method to find their own services? Or is
it better to just pass in a List or Map of dependent plugin references? Ideally,
the engine should allow for "lazy" instantiation of plugin classes. That
is, any class the plugin has as part of its .jar file should not be instantiated
until needed. However, if a plugin is to add a menu item to a GUI app, the
plugin needs to be instantiated in order to do so, thus preventing the ability
for a menu item to activate (instantiate) the plugin.

I believe my engine is generic enough to meet most peoples needs for building
an app with plugin support. There is no limit to the types of plugins that
can be created.

Please respond via email. I would appreciate any thoughts on this, and will
explain in more detail any questions.