Most likely because it’s probably* impossible.
* I don’t deal in absolutes. But I’m pretty sure it’s not possible.
1 Like
I am pretty sure its possible, it just won’t be able to cover the complete SpongeAPI. What can be “fixed” using the Null Object Pattern (just makes sure plugins don’t crash but may break them) And it will be a lot of NMS. I just hope he makes his NMS code smart (this class can find nms from 1.3
2 till 1.7.10), or their will be lots of complains from people running 1.7.10-1.4.7.
(their is something wrong with this wall of text 
)
1 Like
I am mainly targeting non-Minecraft Bukkit API implementations (Glowstone and Glowstone++, but Bukkit2Sponge doesn’t yet work on the latter due to this bug), so for better or worse won’t be able to use NMS.
I’m thinking the way around this it to enhance the forks of the Bukkit API as needed to add support for required functionality needed in SpongeAPI, but of course this does introduce the complication of working with the respective teams to keep the API forks (Spigot-Bukkit, Glowkit, and Glowkit/Spigot-Bukkit) synchronized. For now I’ll probably stick to what can be covered on common ground.
1 Like
Including javax.inject:javax.inject:jar:1 in the shaded jar.
I would say, try to relocate javax.inject because the javax package looks kinda sealed.
I’ve been working on something sort of like this (a plugin API that works on Bukkit and Sponge), maybe in the future I could contribute some work.
To be honest, I once tried to work on my RPG plugin project to make it platform agnostic such that it would work on both Bukkit and SpongeAPI, but alas, I’d be reinventing the wheel with the strides SpongeAPI has made.
To be honest, from my personal point of view, I once worked on plugin commissions for Bukkit and as soon as I started questioning the amount of bloated logic to perform some basic operations with Bukkit/Spigot’s API, I stopped doing plugin commissions.
In general, I wouldn’t want to contemplate having a SpongeAPI implementation on CraftBukkit/Spigot because of the amount of differences the two API’s have, it would be incredibly difficult to try to implement, unless you’re creating a SpongeAPI implementation directly on top of Spigot.
Again, this is all my personal opinion.
4 Likes
I just wanted to start a topic of all implementations yesterday. Good luck, I will be needing this in some time 
Unfortunately I am extremely busy right now, otherwise I would like to help
Thank the lord.
#SpigotIsTheUltimateServerAndNothingWillEverBeBetterThanIt
Also, I may help this. It’s pretty neat.
Um… No. I don’t even.
9 Likes
Care to support that claim?
8 Likes
Ehm, I hope you realise that a lot of plugin devs are dropping bukkit support. So after some years, you can come back and try to defend that statement 
.
3 Likes
This seems like a lot of work for little gain if you ask me. This is like dropping a turbo charger in a Geo using duct tape. IDK about the rest, but I don’t plan on supporting my bukkit plugins for very much longer. Hell I’ve been dragging my feet on the fixes I need to push out simply because fixing bugs in a dead project is un-motivating. Good luck to ya.
3 Likes
Notice how people come from Bukkit, to here. What would be the use of having it for Bukkit? Seems everyone will switch out of Bukkit anyways, instead of to Bukkit.
1 Like
We could use it on modpack servers .
nice 
but my moded servers are still in 1.6.4 so no chance to use it 
Switching to Bukkit is like beating a dead horse…
Sponge will definitely be the best option when it’s finally released.
Spigot is just the try to let Bukkit last the bit longer that takes Sponge to get done.
2 Likes
That is what I am saying
1 Like
Fixed, Bukkit2Sponge now works on both Glowstone++ and Glowstone. ++ had to include the jsr305 jar for these annotations, which were moved out of the Guava package, but SpongeAPI had a different version causing the conflict. Could have relocated maybe, but it was only used in one place in the server so I just removed it.
Released Bukkit2Sponge 0.0.2 improving version compatibility, should work on 1.6.4 now. Also tested on briefly 1.7.10 and 1.5.2 (and 1.8.3).
The Bukkit API has been fairly stable over these versions, the main problem was incompatible library dependencies. Solved this by relocating Guava and ASM within Bukkit2Sponge at build time and runtime in the plugin class loader using ASM RemappingClassAdapter, so they do not conflict with the server platform version (Guava 10 in Bukkit 1.7.10 and earlier, Guava 17 in Spigot-Bukkit 1.8.3 and Glowstone++ 1.8.3, but 10 in Glowstone 1.8; ASM 5 vs ASM 4, etc.). Not sure how long I’ll be able to maintain backwards compatibility as more features are implemented requiring newer API, however.
3 Likes
I don’t mean to be rude but this seems extremely pointless. The whole reason why Sponge was created is because Bukkit is more or less obsolete. This is a waste of time in my opinion.
6 Likes
This is definitely not pointless. It will take a year or two until Sponge a) is stable AND b) has enough plugins to move from one of the Bukkit API softwares. There are servers that rely on plugins they wrote or edited themselves. Some of them require NMS or are too complex and cannot be loaded by Pore because of that and it’s pointless to port the changes of edited plugins to their unstable Sponge builds. And even if you made the transition, users that do not need client modding will have little to no benefit from the change. Sponge will be better, but Bukkit is a well working and feature rich API, as well. It always did everything we needed. So why should we rush the transition? In my opinion, that would be the true pointless thing.
3 Likes