I am abandoning this idea since Spigot is out. I do not have time for Sponge. No time for waiting, no time for learning a new API, I am a busyman. Now I can get back to my (Bukkit) track.
The concept is simple. An automated plugin converter that can port Bukkit plugin to Sponge.
I am currently considering a tool, that will read in Bukkit plugin source code and implement them correctly with sponge. Sponge and Bukkit may have similar ways of implementing listeners etc.
For instance this pinned post described some differences. But I believe Sponge will make their API very similar to Bukkitâs.
Obviously not all the code could be be converted. After the conversion process, those nonconvertible code will be marked in the output. So the main concept is, converting as many code as a machine can, then we can manually fix the others.
Ps: I wrote ~90 (now using ~20) plugins for my server, and I am the only one who manages it. Converting all of them by hand by myself will bring me a huge headache.
And at last letâs say we are ignoring NMS for now⌠NMS are useful sometimes. EXAMPLE
Itâs not really so much as that I donât think it would be possible. There are plenty of clever, intelligent people who could pull it off.
My main concern would be the dependence it would create in some programmers, and the bugs it could create that the dependence makes programmers blind to.
True Java beginners (Like myself) could not be able to code after it gets auto converted because we/they wonât understand Spongeâs API. They will probably make all the pluginâs they make in bukkit then convert.
@FerusGrim@LordLambda
Actually my point was making a tool to save time for those developer/plugin porters. It does not have to be perfect, itâs just a tool that will do some mechanical replacement for grammar/format/plugin.yml etcâŚ
Imagine before someone has to port a plugin, he has to convert plugin.yml into (annotation)Plugin(blah blah blah), this tool will do it.
Edit: I meant, doing exactly same things for each plugin doesnât seem to be cool. This tool will minimize those boring process.
Well yea, but why is there a need to port it? With Pore, I can just drag, and drop the plugin in, and load it with pore. No converting at all. No need to convert plugin.yml, etc.
Architecturally, writing Pore as a âshimâ layer, and implementing an autoconverter are going to run into the same challenges. Differences in the underlying object and event models between Sponge and Bukkit may make it very difficult to achieve a100% compatible implementation of Bukkit in Pore, and similar constraints will exist for any attempted autoconversion. We will have to see what the API looks like when the initial API is released later this month to gauge how possible this would be. For sure it is not going to be easy.
I considered this upon the inception of Sponge, but abandoned the idea the next day on the grounds that it would be extremely difficult to write, and even more difficult to perfect. Due to the nature of such a utility, it would need to create a near-perfect port of the plugin, which could take several months of work to achieve. I created Pore shortly before abandoning this idea, which I view as a much more intuitive solution. Itâs much easier to translate each call on an individual basis inside a standard method than it is to parse the Java code, determine exactly what it wants to accomplish, and inject any necessary conversion code. The Sponge API isnât a 1:1 copy of Bukkit, so you canât just replace method calls. Thereâs a lot of structural rewriting that needs to be done to port existing code.
To go off-topic for a moment to address this concern: our goal at the moment is to focus our time on translating the most commonly used API features first, and the more obscure ones at a later time. This should speed up the first part of development considerably, since those features are also likely to be the most similar to their Bukkit counterparts. My mindset is that itâs better to have 80% of plugins 100% working than 100% of them 80% working.
So what you want is something that would turn this code:
public class DummyBukkitClass extends JavaPlugin {
@Override
public void onEnable() {
// Some Profound code can be found here
}
@Override
public void onDisable() {
// The Profound code is now ending =(
}
}
Into this code:
//TODO: Change Arguments to better suit your needs!
@Plugin(id = "PlguinID", name = "Human Friendly Name", version = "Version Number")
public class DummySpongeClass {
//TODO: Change Arguments to better suit your needs!
@SpongeEventHandler
public void onEnable(ServerStartingEvent e) {
// Some Profound code can be found here
}
//TODO: Change Arguments to better suit your needs!
@SpongeEventHandler
public void onDisable(ServerStoppingEvent e) {
// The Profound code is now ending =(
}
}
Is that what you are thinking of doing in a nut shell? If so, the changing method names and arguments is easy to do, however as you stated above, getting it âPerfectly portedâ would be near impossible.
I was making this but put it aside till i can get the real API on my hands. If you would like, I can post the source. (itâs not pretty, but itâs something). Maybe it can give you ideas. =)
So, in my understanding is what you are trying to do, is to create a language translator (like a Coffeescript to Javascript compiler), but for Java code written for Bukkit, to Java code written for the Sponge API. Those things arenât very different, right?
As you say, the concept is simple, but i think the implementation is very hard. You have to write a complete âcompilerâ to analize your code, tokenize it, parse it, and finally translate it to Sponge code: packages, classes, fields and so further.
This is a lot of work, and i think that most plugins are already ported at the time you finish this tool. But on the other side, writing compilers, interpreters, translators etc. are generally good and challenging exercises, and is good practice.
If Pore can do 90%, that may be good enough for many plugins. Most of the incompatibilities will not be subtle and will immediately manifest themselves, I think.
Yes, and I know perfectly porting is near impossible, but this tool could try its best to save our time. The reason I am considering this tool is because I personally write âfunâ modifications for my server.
Since Bukkit is dead, I have to move on. Complete rewrites seems to be yawn because there are ~14 plugins with ~3000 lines of code in total needs to be ported. I do not use FrameProtect, I do not use HorseProtect, I do not use FriendlyHoppers etc⌠I have my own implementation that will maximize performance with minimal code, and thatâs why I have done so much on plugins.
Anyways if I am able to manage all of my code in Sponge API will be seemingly clean and tidy.
apologies if this counts as necroposting, iâm relatively new to the idea of being active on a forum
honestly i find there shouldnât be a need for a porter because that adds a method of laziness to the process of conversion. lazy processes almost always have a problem, and like previously stated itâd probably take too long to finish this project where this lazy process becomes obsolete, unless youâd want to try and revive a dead bukkit plugin using the original source or something like that.
with the method of manually porting it over you can always do some clean up and some optimization of the code, which is always a good idea since its bound to show improvements. redoing your code line by line gives you a chance to re-read how you executed a certain action and select if you should leave it as-is or if you can make it better.
tl;dr iâd rather have clean, new and improved code than old, processed and potentially buggy code.
I havenât seen anyone really say âNECROâ more so on a topic like this.
I hope you become a regular with the sponge community! I look forward to seeing more from you
While I agree that starting a plugin from scratch has itâs pros, it also has itâs cons. One pro is that it could be better optimized. One con would be that it takes too long to re-write (Why re-invent the wheel?). People are lazy, thatâs a fact, people will want their favorite plugins as soon as sponge hits. I could see people using this, or The Pore project, to revive an old project to start off. Eventually things like this and Pore will loose usefulness and will no longer be needed; until that time comes I think they should still put forward the effort.
tl;dr I agree and disagree. Over time this will become less useful. But for now, they should still work on it. IMHO
This sounds like a really cool concept. I dont code so i cant really add to the discussion but i can deffinatly say that as a server owner, it will be great to not have to wait for plugin authors to port their plugins if this awesome idea works outâŚ
