[WIP] Addon Manager

Discussion in 'WIP and Development Status' started by Superckl1, Jan 11, 2014.


Will Addon Manager revolutionize the way plugins work?

  1. Yes! I'll tell everyone I know!

    2 vote(s)
  2. No... I'll still tell everyone I know though!

    2 vote(s)
Thread Status:
Not open for further replies.
  1. Offline


    Originally, this was created for a private server. But, we found it so useful, we have decided to release it to the public!


    Addon Manager attempts to revolutionize the way plugins work. Have you ever updated a plugin, then had to restart your server? Why couldn't you just reload that one plugin, without the need to restart? This is exactly what Addon Manager accomplishes through the use of addons.

    Addon Manager provides an extensive interface for an addon to use. Using this interface allows the addon to be unloaded from memory and reloaded at anytime. This means you can update them whenever you want! No restarts ever again! Even Addon Manager itself is reload safe!


    Since Addon Manager requires an addon to be reload safe, plugins will have to port over to our API. All that requires is changing their registration with Bukkit to use our registration methods (and JavaPlugin to addon). It's that simple! If you are a plugin developer, we beg you to help us get this off the ground. Just leave a post here or send me or Fireblast709 a message saying you would like to help. You'll be the first to try out our API once it's ready!

    Project Page



    We are in the middle of writing the API.
    We have 0 (aww :() addons for launch.
  2. Offline


    This is a nice idea, but you are missing some much needed things...

    Since our plugin/Addon will have to depend on AddonManager wouldn't it be best to move this over to maven so that we can handle this as a dependency much easier. (Move over to maven for better dependency management)

    You are missing documentation in your code. There is no javadocs in AddonManager so how are we supposed to know what each thing does. You don't even have an example to show us.

    Lastly, If you fix those two things i will gladly help out and create some small plugins for this.
  3. Offline



    Thanks for your support! If you noticed, the status is that we're in the middle of writing the API. It's not nearly done yet. :p Fireblast709 is actually working on eliminating the addon.yml in favor of annotations right now. I've edited my previous post to reflect that.

    Once again, thanks for your support! I'll send you a message (and make a post here) when the API is ready for developers to start.
  4. Offline


    Sorry for me not being that educated on your idea, I didn't read it all. :p Although, from what I read, may I ask what features you plan on including that would differ from a plugin such as PlugMan?
  5. Offline



    The idea behind this is that it allows addons to be completely reload safe. Plugins that use Runnables and async threads will usually give a nice juicy error when reloaded (and maybe not reload properly). This plugin is an attempt to fix that.

    Edit: It was also act as an interface between addons for things like economy. Sort of what Vault tried (and arguably failed) to do.
  6. Offline


  7. Offline


    Isn't there a bunch of plugins that also reload certain plugins....? why is YOUR one going to revolutionize... anything?
  8. Offline


    Dread9Nought First I like to mention that our system is going to use 'addons' rather than plugins. We implemented a system for sharing data that allows you to access the data of another addon with a simple getter, and that data will persist over reloads. In theory we will be able to asynchronously load and unload addons without worrying that other plugins will miss data (given that the dependencies are strictly based on the shared memory, and that there are only thread-safe Bukkit methods used in the startup process of the addon)
    Also, since we work on 'addons', we are free to manipulate the classloaders and their loaded classes. Plugins that simply reload plugins are much more restricted in this case.
  9. Offline



    Would you mind taking a look at our current API on Github? I'd like to know what we're missing (besides a few more examples). You can find a basic (really basic) example here. I plan to add to it more to make it more complex in the future.

    Right now, we're struggling with BukkitDev to get the name Addon Manager. This plugin already has it, but it is obviously abandoned :oops: .

  10. Offline


    Superckl1 I will write 2 of my plugins for AddonManager... Hubber & TimedSounds

    As of 11:35 PM here is what i have to say after writing Hubber...
    • At first it took me a while to figure out that i have to use getPlugin() in order to do most of the stuff of JavaPlugin/Plugin
      • You should fix that because i almost wrote my own getConfig()...
      • Edit: Did write my own getConfig();
    • Looking throught the code its actually rather nice (all except for this stuff... it should have a separate area and not be in the same class that is extending JavaPlugin)
    • Overall after about 40 minutes on it, i would say its rather well put together, but it could use
    • some touch-ups
      • Better Dependency Manager
      • An easy way to get another addon... AddonManager.getAddon(String addonName)
    • I think this can handle small addons/plugins very easily but will get harder as the plugin/addon gets bigger
    Tomorrow i will write TimedSounds and see how it handles Runnables (if its the same way as a normal plugin then it shouldnt be any problem what-so-ever

    Edit: TestAddonPlugin Repo ---> https://github.com/Goblom/TestPlugins-AddonManager
  11. Offline



    Thanks for your feedback! I'd really appreciate you testing AddonRunnables, I never got a chance too.

    We were meaning to write a getSuggestedConfigFile method, but we must've forgot. We are planning on having each addon be accountable for it's own Config

    As for getting other addons, you shouldn't have too. Addons should store all data in the persistent storage (by annotating @Persistant) so other addons can access them without storing any references to other addons that would prevent them from unloading properly.
  12. Offline


    Superckl1 I was just pointing something out...

    Bukkit has
    Bukkit.getServer().getPluginManager().getPlugin(String pluginName);
    So it would be nice to have something along those lines because in some of my plugins (for example hubber i did this)
    public static Hubber getPlugin() {
        return (Hubber) Bukkit.getServer().getPluginManager().getPlugin("Hubber");
    And i am unable to do that with AddonManager.

    For that getSuggestedConfigFile just use getConfig() and do something like this in Addon.java...
    public FileConfiguration getConfig() {
        return getPlugin().getConfig();
    public void saveDefaultConfig() {
    Maybe also change getPlugin() to getAddonAsPlugin().... because some people like to make "getPlugin()" into a static refference

    Edit: I can ealsily break AddonManager... getAddonManager().getAddons().clear();
  13. Offline



    Thanks for the suggestions! We are really torn on whether to add a way for Addons to get references to other Addons. If one Addon has a reference to another, the other Addon will be unable to unload unless the one with the reference is also unloaded. As you can imagine, that's a bit of a problem. :p That's why we came up with the persistent storage idea. Addons can access each other's data without storing references to other Addons.
    For the configuration, we can't just provide AddonManager's config. With many Addons that would become a mess. We will provide separate files for each Addon, in the form of a YAML object.
    Wow, I didn't realize it was that easy. We'll have to look into that.

    Once again, thanks for your help!
    Goblom likes this.
Thread Status:
Not open for further replies.

Share This Page