Is it possible to abstract away Sponge Plugin specific fields and methods

Plugins Plugin Development
1

As a way to clean up my code and focus more on my intended algorithms vs all the overhead needed to set up a plugin, I tried placing all the @Inject modifiers in an abstract superclass. Since I also have a suite of plugins I’m developing, I decided to have each plugin’s main class implement a standardized interface, and extend this abstract ‘plugin’ class. However it seems like this causes sponge/Forge to freak out:

I also tried making two separate but identical abstract classes instead, having each plugin’s main class implement the following interface and the following abstract class:

Interface: http://pastebin.com/GHExWjqD and Abstract Class: http://pastebin.com/54YAz6ei

Basically my aim here is to make the main class more human readable. So my question is, can I do what I’m trying to do? or is there something specific to @Inject/Guava that makes this a fruitless endeavor?

2

From the error log it appears you have two plugins with the same ID ‘geoworld’. Are you sure you’ve changed the ID in the @Plugin annotation?

3

Here are the two plugins @Plugin annotations:
http://pastebin.com/4sHCKrGm for GeoWorld and
http://pastebin.com/GfhxBqkT for IgneousPack

Additionally the gradle.build and gradle.settings files are:
For Igneous Pack http://pastebin.com/ceJGXUJs, http://pastebin.com/2z5QkBJC
For GeoWorld http://pastebin.com/FsmPRMzQ, http://pastebin.com/B8aZKckQ

so, yes, they’re different.

4

I do this for KatLib and related plugins through a constructor annotated with @Inject, and then pass the objects on to the super class. Not sure if it’s exactly what you need, but it’s a thing.

Do be careful about extending classes for the main plugin though. If the abstract plugin class is in another jar from the implementation it might fail to load if the jar with the abstract plugin class hasn’t been loaded yet. This is AFAIK only a problem with SpongeForge, not SpongeVanilla.

5

@Katrix
could you show me an example of annotating the constructor with @Inject?

6

It’s scala, but sure. I’ll try to explain a bit about how stuff works.

Here is the plugin that uses this. In scala the constructor is defined on the same line as the class name. Any field that take more annotations (path for example), get that annotation added in the constructor. A nice thing with this approach as well is that I can say that those variables are final.
https://github.com/Katrix-/HomeSweetHome/blob/master/5.0.0/src/main/scala/io/github/katrix/homesweethome/HomeSweetHome.scala#L82

Here is the super class.
https://github.com/Katrix-/KatLib/blob/develop/shared/src/main/scala/io/github/katrix/katlib/ImplKatPlugin.scala#L35

If I were to use the super class from java it would probably look something like this.

public class HomeSweetHome extends ImplKatPlugin {

	@Inject
	public HomeSweetHome(Logger logger, @ConfigDir(sharedRoot = false) Path configDir, PluginContainer container) {
		super(logger, configDir, configDir);
	}
}
7

@Katrix,

Finally gitted it all to gh.
Relevant packages :
“Master” Plugin

“Slave/Side” Plugin

Slave Plugin:
Main
abstract

Main Plugin:
main
Abstract
Interface

I still have that same ID conflict unfortunately : /