Osmium API (Bukkit/Sponge Abstraction Layer)

Plugins WIP Plugins
1

Osmium

Osmium is server API that acts as an abstraction layer for Bukkit and Sponge. This means that any Osmium plugin will run on any Sponge or Bukkit server that has Osmium installed. Which for plugin developers translates to no more having to duplicate all your platform specific code just to support multiple API’s

Osmium is mainly intended to be used for simple plugins in order to target multiple platforms. The focus right now is more so about making it extremely easy to complete common tasks than it is to implement a fully fledged Minecraft API.

This project is completely different from Pore which allowed Bukkit plugins to run on Sponge. With Osmium, plugin developers write code for the Osmium API (different than Bukkit and Sponge) and then when their plugin is compiled, Osmium generates necessary files to make it load and run as if it were a native Sponge or Bukkit plugin.

Osmium also makes it extremely easy to switch to a specific platform if necessary. For many tasks, plugin developers can simply use

if (Platform.isSponge()){
  //Sponge specific code
} else if(Platform.isBukkit(){
  //Bukkit specific code
}

Main Goals:

  • Extremely concise and intuitive API
  • Portability: Any Osmium plugin should work on Bukkit or Sponge servers
  • Consistency across server platforms

Some Cool Features

Automatic registration of event listeners

	@Listener
	public void on(PlayerTeleportEvent e) {
            //This is all you need for this event to be called. No listener registration
	}

Schedule entire methods

	@Schedule(async = true, interval = 3, unit = TimeUnit.MINUTE)
	public void update() throws IOException {
            //This is an async task
	}

Save data easily

	@Persistent
	public static int maxLikes = 0; //This field will be the same across server restarts. Zero is the default value

Automatic registration of commands. Also amazing command API (in progress)

@CommandProperties(aliases = { "test"}, usage = "test <run/info> {player}", admin = true, console = true) //Commands are player-only by default
public class TestCommand extends Command {

	@Override
	public void configure() {
		add("info").setExecutor((e) -> {
			e.sendTitle("&aThis is a secret message for admins");
		});
		add("run").setExecutor((e) -> {
			e.getPlayer(0).sendMessage("You have been tested");
		});
	}

}

Configurations

@Configuration(path = "plugin.conf", header = "Here is the config file for my awesome plugin!")
public class Config {

	@Setting(comment = "Set to true to enable debug level logging")
	public static boolean debug = false;

	public static class Database {

		@Setting(comment = "Set to true to store plugin data in a MySQL database instead of SQLite")
		public static boolean enableMysql = false;

		@Setting(comment = "The address to access the database")
		public static String host = "";

		...
	}

}

Project Details

DISCLAIMER: Osmium is not in a usable state at the moment but feel free to experiment with it if you would like. I’m only posting it here for some feedback and because I intend to be releasing a few plugins which use the API. Any suggestions or constructive criticism would be appreciated :slight_smile:

GitHub: GitHub - kmecpp/Osmium: Abstraction layer for Sponge and Bukkit that allows for development on both platforms simultaneously.
CI Server: http://ci.kmecpp.com
Discord: https://discord.gg/jBjYckt

2

standards

3 Likes
3

To elaborate: There is no market for anything like this. People only use Bukkit at all for the massive existing plugin library. If they had a choice from a massive Sponge plugin library, Spigot would stop getting newcomers altogether.
Also, as I mentioned in the other thread, since the Bukkit API is significantly worse than the Sponge API, your API can only cover the lowest common denominator as there would be no point whatsoever to an Osmium plugin which only works correctly on one implementation. Your API must by definition be as bad as the Bukkit API and as convoluted as the Sponge API, at least where it abstracts over Minecraft (commands, for instance, being an exception).
If you invested your development energy on maintaining Pore, and got flagship Bukkit plugins to a working state with it, you would get an actual audience. Not so with yet another API that nobody wants.

1 Like
4

It’s not really clear who you mean by people. Plugin developers or server owners? I’m not targeting server owners and plugin developers don’t normally care about the existing plugin library unless their hooking into another plugin to add functionality or whatever.

The target audience currently would be developers making new and small plugins who want to support multiple platforms. And I know there are at least some people who would use it, because if Osmium did turn out to be a good API I would write 95% of my plugins with it.

My intention is NOT to create a fully fledged Minecraft API. I recognize there are differences in Bukkit and Sponge which would probably make this impossible. In those cases it is up to the mod author to handle what happens on each platform. This way only the best parts of each API can be used and it wont be as bad as Bukkit or as complex as sponge.

The goal of Osmium is to be extremely concise and make it easy for smaller plugins to be cross compatible. Even if only 10% of a plugin uses Osmium I still think thats enough to save developers loads of time.

I believe ryantheleach said it best in the thread you referenced:

Also

If Osmium plugins only worked correctly on one implementation then clearly the project would be an utter failure because the whole point is to make it work so that plugins are cross compatible.

All useful flagship Bukkit plugins already exist or have an alternate Sponge version so I don’t really see what use Pore even has anymore. I’m sure you could also agree that a better solution to that problem would not to maintain Pore, but to have a larger developer community making more Sponge plugins.

5

Honestly, regardless of my feelings about things like this, if its something you enjoy doing, I wish you good luck.

I haven’t had time to look through the code much, but have a couple questions:

  • Are you wrapping events, or listening for events, and then re-firing your own custom events?
  • Does your system load plugins independently, and if so, does it follow the typical lifecycle of sponge/spigot, or does it have its own?
6
  1. Wrapping events
  2. Osmium has an annotation processor which generates necessary meta files (plugin.yml, mcmod.info) as well as two class files which are the entry point for each platform. These classes extend from normal entry classes so the plugins load exactly as if they were native to whatever platform they are running on.
7

@kmecpp You may also want to look into Joining / Merging / Learning from (and then competing with) Wet Sponge if it’s still going.