How to make an API?

Discussion in 'Plugin Development' started by Jozeth, Jun 23, 2013.

Thread Status:
Not open for further replies.
  1. Offline

    Jozeth

    How would I go around adding an API for my plugin, so if they add it under "External jars" (on eclipse, like bukkit.kar they can implement methods/calls into their plugin to get stuff from my plugin.
     
  2. Offline

    Alex5657

    You cant put it inside the jar. You will have to write the directory to it to the classpath in the manifest file and store it in the directory you specified.
     
  3. Offline

    !Phoenix!

    Wikipedia: API

    At first: An API is not "the very one thing" that allows other plugins to interact with yours.
    I could add your plugin to the "external jars" of my plugin and then use any function it provides already now (Only if your plugin is running on the server, of course). E.g. I could get your plugin's instance using the Bukkit API and then call the "onEnable()" or everyOtherFunctionYouImplemented() in your plugin.
    An extra API can only ease the access to certain functions of your plugin plus allows you to 'notice' that there is an external access, which might require some more things to be handled.
     
  4. Offline

    MylesIsCool

    Although the other responses may seem vague they don't really get to the point,

    If you wish to add an API you can create a class such as PluginAPI, in this class have a static method of something like getInstance(); returning an instance of your PluginAPI.
    Then if a Plugin wishes to use it they call PluginAPI pa = PluginAPI.getInstance();

    Or you can let plugins do something like MyPlugin x = (MyPlugin) Bukkit.getPluginManager().getPlugin("MyPlugin"); which ofc ourse isn't really an API.
     
  5. Offline

    Wingzzz

    Implementation + API:
    If you have 2 parts, implementation and API then look into maven for its dependency management and its shading plugin. You can then work on the API consisting of a lot of things such as utility classes, wrappers, abstraction, interfaces etc.. Then use it as a dependency in your implementation having set the "plugin" or "api" whichever you want to call it to make sure it will allow it to call these new methods from your implementation. In this case you're trying to make an API that contains a lot of helpers and utilities like regularly, but more so you're trying to make a bridge. A jar that others can download and use methods, classes, etc that are safe for use in the long run. To achieve a "uber-jar" containing both your implementation and your API (that's how CB/Bukkit works in how you only just import Bukkit for a short while and don't actually put it inside your plugin) is by using maven shading and having your api dependency in your implementation as a <scope>compile</scope>. (Sorry I explained this poorly, I will have a good example of this from my coming project Civilizations soon, as well look at how Bukkit uses its API in the implementation of Bukkit.setServer(this) inside of CB code).

    Standalone API:
    Now, if you are looking to make a standalone API for Bukkit, you will need to ensure it has full plugin capability, extending JavaPlugin etc... Then this way people who use your library just simply download the jar, have it on their server and when they make their plugin, just add it to their build path. It's entirely up to the magnitude and design of your plugin/api as to which road you take.

    If you have any questions please feel free to pm me, I'm sorry I explained it poorly, but I have a great deal of experience in this as I've been spending probably the past 2 months learning from the ground up on how to go about this in those two ways. Even having now an API for all my implementation's APIs to depend on. Thus even further cutting down on redundant code.
     
Thread Status:
Not open for further replies.

Share This Page