One of the things that hMod is missing is a good inter-plugin communication system where 3rd-party developers can call stuff directly from another plugin. Is there going to be such a system developed into Bukkit? The repo system would allow dependencies to be pulled alongside the plugin itself, presumably, and the system could be constructed as to encourage code-sharing at the same time as ignoring unused code. To put it simply, a modular repository system would be great.
would be nice, the easiest way i can think of doing this is ask the Server for a plugin by name have it return an Object class and then the plugin would have to cast it to the correct Class, then we could just call methods on any plugin (also have a way to get a list of plugins from the server so we could loop through it as well)
All of the plugins in bukkit have to be package based which is a core idea of java but this also means that calling stats from other plugins becomes far more easy and as nijiko said it is already in the works as far as I am aware.
Btw, are discussions of that kind happening somewhere? It would be interesting to see what is being proposed.
Inter-plugin communication has been one of our focuses from the beginning. We did not agree with how hMod went about things as it created issues when a plugin like CraftIRC wanted to work with ChatChannels - a completely new plugin combining them had to be made. Please note: the only Official source for information on the Bukkit project is myself. Or, if I am absent, Dinnerbone. Anything said by anyone else is their opinion and should not be considered truth.
Thank you for your very inspiring comment. Let me rephrase that, I thought it was already possible. I was more or less referring to the use of static members to accomplish inter-plugin communication, believing they were talking about more methods and such in the Bukkit kit to access other plugins What I believe was currently capable would be something such as: Code: public class SamplePlugin extends JavaPlugin { public static SamplePlugin instance = null; public SamplePlugin( PluginLoader pluginLoader, Server instance, PluginDescriptionFile desc, File plugin, ClassLoader cLoader ) { super(pluginLoader, instance, desc, plugin, cLoader); instance = this; } public void doSomething() { } } I would then add SamplePlugin's jar to the build path of my other plugin and then invoke doSomething() from the plugin via Code: SamplePlugin.instance.doSomething(); But it seems that the test I conducted on it does not seem to work, possibly because I can not set which order the plugins are loaded. I'll have another look at it in a bit, however I was able to invocate methods of other plugins I created through these means while using hey0's mod and enabling the plugins in a manual order, I'll have to review my past works. Off the top of my head, I can think of possibly changing the classloader variable used in the super() call of the constructor in my second plugin to match Code: SamplePlugin.class.getClassLoader();
It really isn't hard to call methods in other plugins if you know the name . Of course, with the inter-plugin api it'll be easier, but if it were an absolute must you can just as easily use Reflection (I wouldn't recommend it, it's slow) Code: JavaPlugin plugin = plugin.getServer().getPluginManager().getPlugin("Wat"); Class<?> pluginClass = plugin.getClass(); Method doSomething = pluginClass.getMethod("doSomething", String.class); Object result = doSomething.invoke(plugin, "wat"); // object.getClass().getDeclaredField..... but of course it can very easily be adapted to use other classes in the plugin (static or non static), etc etc Not that you'd want to constantly use reflection, maybe not at all considering they're working on it now
I am all too familiar with how to use the reflection API, and the quoted snippet is only one of the reasons I stray away from it, let alone didn't even bother mentioning it.