How would I go abouts porting my craftbukkit/bukkit plugin to sponge? I am interested in exploring this option and will also look into the Lapis Blue project as well.
The easiest way to port your project would be to stop using Bukkit and start using SpongeAPI.
True but I meant more in the essence of switching my plugin to a sponge plugin. Are there any ways to make it compatible/work with sponge other than completely recoding it?
Only if you abstract out anything not related to Bukkit (Managers, specialized APIs, etc). I would assume that for the most part, most plugins were designed pretty closely intertwined with the BukkitAPI.
No. Currently, there are no plans to make them compatible in the future. I find it surprising how many people think we should natively support a software besides our own, actually.
The Bukkit and SpongeAPI are similar in some aspects, and a world apart in others. You will have to learn many things entirely over, while other aspects may come naturally.
I would recommended starting by reading over the Creating a Plugin docs.
For people that want to port a plugin, perhaps we should have a portion of the docs dedicated to common features/concepts of the Bukkit API and how to port them to Sponge’s features/concepts?
I like that idea very much and it would be awesome if that came to fruition.
Maybe in the far-flung future, when we’ve finished documentation Sponge’s features first.
But even then, we’d need to decide if that’s even for us to do. Supporting other, dead software is ridiculous by most standards.
So just like it.
But helping others that used that software, especially when it was/is as big as it is, that is something that seems like it should be done and how your software can grow. It is essentially like shooting yourself in the foot (not doing it).
In the same way that Windows supports Linux? Or how PS4 supports the Wii U? Or how Steam provides RS Social Club support?
You’re absolutely right, we’d be shooting ourselves in the foot to not support a large, but entirely unaffiliated, dead, non-official-updating, separate piece of software. It’s all coming together, now.
but yes, i do agree that supporting a soon to be completely dead project isn’t entirely plausible; in the long run its a waste of effort since it’ll soon be gone and no longer looked at. plus, its a lot better to rebuild your plugin from scratch than it is to try to port an old build that you can probably do better remaking. supporting the old project is elongating its lifetime, and considering that time can instead be used to learn the new api and experiment with it, it can be counted as again, a waste of effort, and more importantly time.
No need to be so defensive. I was not trying to argue and no need to be so sassy.
To be honest, you could at least try to be objective. Nearly every server is using CraftBukkit or a CB mod right now. The Bukkit API has more features right now and you can do everything that doesn’t require client modding if you use NMS code. For many to most of us, that’s enough. It IS still in active development, see Spigot, Glowstone++, Pore and SportBukkit. In addition, there are not that many devs who drop support for Bukkit as team “the apocalypse is near” always states. Even for those like BKCommonLib, new devs try to tackle the update. There are less guys who want to port their plugins to Sponge than guys who keep support for Bukkit, right now. Mojang doesn’t want to change so much code in 1.9, so the update will not hurt Bukkit much. I do not think that Bukkit will die in the next 1-2 years and it’s pointless to make future plans for more than this.
So all in all, I consider Sponge to be interesting for those who used Cauldron before, but those who used CB will have little to no benefit of the transition.
Well spoken. I have used both btw haha. The ones (like me) using CB will eventually have to find something new however if/when it eventually does go.
I enjoy sarcasm.
Unless the project is handed off to someone else (by Mojang), there will never be another legitimate release. The people who continue to develop it do so with debated legality.
The real issue at hand here is that we aren’t the Bukkit team. The constant requests for us to support and/or write guides for transferring is… kind of insulting. We’re a separate entity, with no wish to associate ourselves with Bukkit.
With that attitude, I’m surprised that people switch over Sponge at all. It’s in your interest to provide easy transition, by this you’re supporting Sponge, not “insultingly supporting Bukkit, what a blasphemy”. See for example this big applications .
There is only so much we can do to ease the transition from Bukkit to Sponge. It is a completely new API, so there is no easy way to port a plugin other than a rewrite. Bridge-type plugins may work for some, but it still adds unnecessary load to a server and uncertainty in terms of stability.
It would be a phenomenal undertaking to explain how to transition between the two APIs for every feature. Any third party is welcome to attempt it - it seems a useful idea - but it isn’t the sort of thing we want to host on SpongeDocs at present. Priority has to go to our own API and implementations, work on which is still in progress.
The reason to not write such a tutorial is the work needed to get this done. We’re extremely short on workers and time, so focus is currently laying on getting Sponge done and documenting everything as good as possible.
There isn’t THE way to port a plugin as many plugins use NMS code, which isn’t possible in Sponge. And Sponge handeles things in others ways than Bukkit, this makes writing a simple porting tutorial even more difficult.
You see, it’s not about us not wanting to do it but about wasting countless hours, which would better go into developing and documenting to provide a clean and easy start for new devs on sponge.
Woops, realised the above written may sound harsh or rude. This was not meant to be this way Most people posting here are very friendly and trying to help you