I decided to make a topic about this so that people are able to get work done and we can get everything rolling as soon as the first release comes out.
The best way, in my opinion, is to just make a plugin shell. The way you can do this is make all the code that is not related to the a certain server API, and then fill in the blanks later. The way I mark the locations is by putting in TODO comments. These can be made by doing this following:
// TODO get player from event
Most IDEs will put in a notification for you so that you can easily find the place to do it. An example way that I do it can be found below.
I hope this is helpful, and if anyone wants to give any input to this please feel free to make a post with your suggestion below.
I suppose you are talking about creating a skeleton-code plugin.
To further what you said above, I suggest that plugin authors include all non-Bukkit API code into plugins now if they want to port early. For example, if you have some SQL code or JSON parsers in your past plugins, you can probably port that code over immediately.
Another good way to prepare is to take your current code and abstract the hell out of it. For example, you might originally have a PlayerManager where you can get your PluginPlayer objects from. You might have a method like
public PluginPlayer getPlayer(Player player) {
// Code here
}
A Player object is, obviously, a Bukkit Object. However, all minecraft players will have an UUID, so you might as well use that instead. Most load/save methods store by UUID now, so this shouldn’t be a problem.
If you still want it to be compatible with pre-UUID versions, you can create an abstract class which states there are methods such as load() and save(), not specifying if they use Strings or UUIDs, since your implementation will take care of that.
I think writing code you can’t test end to end is mostly a waste of time, and there’s no end to end until there’s a Sponge server implementation. If your code is already modular and unit tested, then you don’t get any additional test value by copy/pasting it over to a new project where your unit tests are the only code drivers.
If it’s not already modularized, modularizing it without knowing what the sponge API will look like will just mean re-organizing it again when Sponge shapes up, so you’re refactoring twice (double the risk, double the bugs) when you could just wait and do it once. Also, there’s a risk of abstracting way more than you have to, which means more code changes and more risk and more bugs - better to wait and see what the minimal set of changes you have to make are, and then make only those.
I say - focus on making reasonable testable improvements a little at a time. That’s what I’m doing with GriefPrevention - continuing to work on it over on BukkitDev while I wait for Sponge to start looking sane. When Sponge starts stabilizing, I can then see what the minimal set of changes to switch over to Sponge will be, so I can minimize risk of adding bugs while porting, rather than going hog wild on getting code out of event handlers when many of those event handlers might actually look very similar in Sponge.
If you don’t take my advice and start trying to abstract your code anyway, at least remember to write the unit tests FIRST, make sure they work on your old code, and THEN make code changes. Otherwise you’re chasing bugs in tests instead of bugs in product code.
