Since the Sponge API is scheduled for release relatively soon, this means that work can begin on a 'bridging' mechanism to allow Bukkit <-> Sponge compatibility. As I've probably said before, the 2.x codebase is does not have the internal stability (nor API-design) to support this change. Work has instead begun over on the 3.x branch.

The main advantage to the system above is that it allows the same plugin JAR to be run on two different server platforms (maven can probably be arranged to build two different JARs from this for each platform). The only downside I can see regarding this is that it makes the EchoPet 3 API slightly less user-friendly regarding the platform that developers use (either Bukkit or Sponge). There is always the option of casting, but it's still a point to consider:

OcelotPet ocelotPet = ...;
org.bukkit.entity.Ocelot bukkitOcelot = ((BukkitOcelotEntityBridge) ocelotPet.getBridgeEntity()).getBukkitEntity();

As opposed to the following (without bridging):

OcelotPet ocelotPet = ...;
org.bukkit.entity.Ocelot bukkitOcelot = ocelotPet.getBukkitEntity();

Of course, this also opens up the question of Glowstone compatibility (once the Glowstone entity implementation is finished); it might be possible to support Sponge, Glowstone and Bukkit via the same API/plugin implementation. I haven't yet considered how well it will work with Glowstone though.

If this system fails, two different versions of the EchoPet API and plugin will need to be constructed instead.

Suggestions/comments are appreciated :). I will keep this issue updated in the future with any information regarding these changes.

The old worldedit had a system like that to support both Bukkit and Forge (even tho it never came that fair). Basically the whole codebase was kind of an API and had a lot of abstraction layers for stuf like World, Player and Entity etc...

Perhaps such a design might be worth looking into. (Even tho I think it we'd basically need to rewrite EchoPet from scratch)

From what I have drafted in the Bridge module of the 3.x branch, most of the EchoPet API module can be transformed into an abstraction layer for each of the NMS/Forge/NG (net.glowstone) modules, e.g:

• Pet<LivingEntity, EntityPet> -> Pet<LivingEntityBridge, EntityPet>
• Basic Bukkit interaction player.sendMessage(...) (etc.) -> EchoPet.getBridge(MessageBridge.class).sendMessage(player, ...)

IntelliJ's fantastic search mechanism indicates that there isn't all that much of the Bukkit API utilised in this section of the plugin. In the actual plugin module, however, it might be a bit different... (listeners; commands – Influx needs to be ported over as well; etc.).

From what I m mentioned earlier about using maven to build 2-3 different JAR files, it might be worth making 1-2 other plugin implementation modules for Forge, Glowstone and Bukkit, especially since the Sponge API introduces a new @Plugin annotation instead of onEnable/onDisable (the Glowstone one would probably be covered in the Bukkit one). This brings up something else that wasn't explicitly mentioned above; perhaps even these plugin modules can be reduced down even further (maybe into the API if required?).

Other than that, the only problem thus far is the low-level entity modules. At the moment, there are 3-4 existing NMS modules to handle entity interaction; might be over-doing it a bit in terms of translating everything to this platform bridging system. Of course, what would be required is low-level interaction with NMS, Forge and Glowstone for this to work with Sponge, Bukkit and Glowstone simultaneously (along with the necessary platform detection at startup).

tl;dr: Luckily, EchoPet 3 is already built on a fairly API-oriented design pattern (which is also why it's impractical to built such a system on top of the v2 codebase), which may (possibly, hopefully) make it easier to build this monster.

Anyway, those are my thoughts and planning on this so far.

Hmm alright :) . If you want I can help you with the bridge/abstracting the abstraction layer

\o/

On a side note, Sponge API v1.0 is now ready: https://forums.spongepowered.org/t/4889

It's purely an API for developers to work with.

Is it "testable" yet? Or did they just release an API without implementation for god knows whatever reason?

Spigot is released

@TJ1632 This isn't about Spigot.

After some consideration, I'm scrapping this concept. When v3 development is kickstarted again, support for the Bukkit (+Spigot) API will no longer be provided, as use of an outdated platform will only hinder forward progress. This also means that the 'bridge' will not be necessary (the 'abstraction layer' will still remain intact however).