Plugin Devs, how will you handle migrating your plugin?

For those of you who plan on migrating your bukkit plugin over to Sponge, how do you plan on doing so? What I mean is will you do a complete rewrite? Will you simply make changes to your existing plugin so that it works on sponge?

Edit: Autocorrect doesn’t like “bukkit”

3 Likes

What is a bucket plugin? xD

I am already rewriting my plugin for Bukkit (Because it has not such good performance). I am going to rewrite my plugin for bukkit, and make the changes for my Bukkit plugin to sponge.

1 Like

I know, I didnt start porting yet, but I am currently buzy with rewriting my plugin.

I am not going to begin porting yet. I am on the other hand familiarizing myself with the API itself so porting won’t be so difficult.

Switching out a few interface implementations and replacing NMS access, that’s it

Im rewriting from scratch since i dont feel like porting every bukkit api call for 200+ classes… I’ll make it bigger better faster stronger! Right now im just typing up the API side of my plugin and planning out how it will work.

I will rewrite my plugin once Sponge’s API is released and good to go.
The API will be different from Bukkit’s, so I don’t think you can port it by just making some changes to your already existing code.
You’ll probably have to do lots of modifications to it.

I’ll also be exporting the releases in the latest versions of Java 7 and Java 8 if I can.
So I’ll release the same version compiled with both versions of Java, like plugin_v1-J7.jar and plugin_v1-J8.jar.
There are lots of people that still use Java 6 on servers, but lots of plugins are compiled with Java 7, so they can’t run on Java 6.
I don’t know if I should compile them with Java 6 aswell, because I’ll probably won’t be able to compile Java 8 projects with Java 6 without making some changes.

I made sure to build my plugins around wrapper classes which themselves use Bukkit functions. Lucky enough, my code, outside of wrapper classes, won’t need many modifications.

I’d suggest you do the same, it makes it very easy to port to newer versions of the server as only the wrappers needs changing. Also, with the current Sponge API state, it’s very likely that major changes are gonna happen so it’s a good idea if you want to starting porting already.

I’m working on ChessCraft initially. I don’t plan to do a complete rewrite, but now’s a very good opportunity to reorganise the code a little better - in particular cleanly separating out the model (the game/chess rules etc.) from the view & controller (drawing boards in the world, handling commands, listening to events). The model will then just need a recompile, and I’ll see how much rewriting will be needed once the Sponge API takes shape.

Yep, definitely a sensible strategy. I’ll be doing this with ChessCraft/Checkers even before I know just what the Sponge API will look like.

1 Like

So far, my progress has entailed creating a new branch for each of my plugins which I’ll use for all the bleeding port code. I’ve only just started porting a single plugin, which I began by adding annotations and converting generic API calls like logging to Sponge. I guess the others will follow a similar transition.

I do not look forward to porting all my nms reflection code for custom entities to Sponge’s component system, thats going to be a long few nights.

Just going to rewrite as this will become my main community; there’s really no point in staying at the others when they are susceptible to these types of things (just mho.)

I think I read somewhere that there will be a document of sorts with all the info we’ll need to port our plugins. But don’t quote me on that!

That’s called the API documentation XD

i like to call it the javadocs.

The new new version of LWC already uses an api on top of the server, so I was already able to start Sponge, although it’s not all that useful yet until Sponge adds more :smiley: The project was originally started for Mojang’s official api a long time ago but I guess that’s still not happening soon.

(it essentially is a rewrite though as it’s been in a dev for a long time but no versions that I approve of yet. soon™)

Just planning a lot of planning for now and maybe some psuedo code/util stuff that doesnt need the api. A complete rewrite is certain

-casually writes an actual reply this time-

as of now i’m just rewriting the plugin as Bukkit entirely from scratch so i don’t necessarily have to worry so much of any improvements or bugs to the thing when i have it ported. if anything this is mainly so i have my plan laid out before it comes out.