Complete rework of the template and group system

[TheMeinerLP]

To make the template system dynamic and universal, we need to rethink the layout or the schema.
I was thinking we have "GroupTypes" that are linked to classes on a registry base. The classes can be extended later by modules. The classes or the interface contain methods to prepare the start and stop of the servers/proxies.

• Preparation
• Start
• Stop
• Delete

Now for the actual part of the template system, we make template groups where we make it possible to link several templates like in BedWars. This way we can theoretically determine the startup behavior of each group or implement our own system again.
In this case a template is based on a template group and the group on a server group from the hierarchical level. All this information is managed by name space in registries. To enable a ready API and diversity. All these things are managed by classes. A Template can have the type SpigotTemplate, another PaperTemplate and so on.
These classes indicate which fields exist. But certain fields must always exist.

Example configuration:

{
  "displayname":"BedWars",
  "id": "bw",
  "grouptype": "ServerGroup",
  "preprocessparameter": [
    "-jar"
  ],
  "processparameter": [],
  "properties": {},
  "templategroups": [
    {
        "id": "2x4",
        "name": "2x4",
        "preprocessparameter": [],
        "processparameter": [],
        "properties": {},
        "templates": [
            {
                "id": "MAP_XYZ_A",
                "name": "A Cool Map", 
                "type" : "PaperSpigot",
                "executebleFilePattern": [
                    "paper.*\\.jar$)"
                ],
                "startbehaviour": "ROUNDROBIN",
                "memory": "128MB",
                "preprocessparameter": [],
                "processparameter": [],
                "properties": {}
            }
        ]
    }
  ]
}

If there are any changes, please discuss them under here.
With 'processparamter' and 'preprocessparameter' for group, template group and the template we have many possibilities for configuration.
Name or displayname is for nice output. The other for commands etc.
Properties for plugins.
And the patterns for the jars

[issue-label-bot]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.89. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[GiantTreeLP]

I have updated your example file to be JSON compliant.
I am not sure about the format as a whole.
Especially since JSON is less of a user-friendly configuration language.

We should talk about the idea of "template groups". I don't exactly understand their necessity.

[TheMeinerLP]

The groups should make it possible to group certain templates. That you have one server group with different template groups. This is definitely better than x^n server groups.
Regarding Json, give me a better file format or idea how we could use it. Otherwise by database. But I wanted to add commands to all this

[GiantTreeLP]

A template group is still restricted to one server group, so you just shifted complexity from server groups to template groups. This does not change anything.

This wouldn't even solve the "issue" some people have with -ID at the end of server names, either.

I see no use for grouping templates, given that you still only have a singular template running on a server at all times (this is due to change, but not reflected in any way in your description).

[TheMeinerLP]

Okay then, let's drop the grouping for templates. Let's just make it so that there are server/proxy groups with templates