The purpose of the API-plugin separation is that the API can also be implemented by other third-party plugins (without embedding the full plugin in the jar).
An example for this would be an Economy API and a reference implementation (e.g. plugin with config file data storage). A third-party implementation could be a plugin with database storage, or an Economy plugin that implements multiple APIs.
That's why I propose to rename this template to "api-plugin-boilerplate".
The example API does not depend on the SpongeAPI. Real-world APIs will usually require the SpongeAPI (as soon as Player is used). That means the API is platform-dependent. That also means that it is no easily possible to create a -bukkit implementation, because the API is bound to Sponge.
That's why I propose to rename the plugin subproject to "boilerplate-plugin".
The purpose of the API-plugin separation is that the API can also be implemented by other third-party plugins (without embedding the full plugin in the jar). An example for this would be an Economy API and a reference implementation (e.g. plugin with config file data storage). A third-party implementation could be a plugin with database storage, or an Economy plugin that implements multiple APIs.
That's why I propose to rename this template to "api-plugin-boilerplate".
The example API does not depend on the SpongeAPI. Real-world APIs will usually require the SpongeAPI (as soon as
Playeris used). That means the API is platform-dependent. That also means that it is no easily possible to create a-bukkitimplementation, because the API is bound to Sponge.That's why I propose to rename the plugin subproject to "boilerplate-plugin".
The template structure would look like this:
api-plugin-boilerplateboilerplate-apiboilerplate-plugin