As a potential plugin developer, I like this because I prefer to keep everything in the code as far as possible
As a potential tooling developer, I’m worried because although YAML had its share of security issues, safely and statically inspecting code becomes much more complex when more behaviour is specified in a way that is alterable at runtime.
Then to update SpongeAPI (from the SpongeAPI subfolder)
$ git pull
The main issue with this strategy is that after each clone/update that changes the subrepo references you need to run the following from the project directory
For anyone who wants to use Maven or Gradle for building plugins, my Nexus repo is available also. I have the HeroCraft jenkins building Sponge & SpongeAPI regularly and deploying to nexus.
I don’t think I read that there’d be no Yml whatsoever, they said, “no
Plugin.yml” file… There can potentially still be editable config.yml
files in the plugins folder under the plugin name…
Yeah the plugin yml should be able to be replaced with a header in the main class, but snakeyaml should continue to be included in the project as it is how 99% of plugins store their data and or configs and it works very well. If it isn’t broke don’t fix it.
@Plugin(id = “MyPlugin”, name = “MyPlugin”, version=${project.version})
You can most likely get a Maven plugin to filter your code before compiling, but put ${project.version} within quotation marks, otherwise it won’t compile as a String.
@Plugin(id = “MyPlugin”, name = “MyPlugin”, version=getMavenAppProperties().getPropertyString(“project.version”))
The value for annotation attribute Plugin.version must be a constant expression, so it won’t be possible to get the version from methods.
It’s certainly a lot better than having a plugin.yml when all you have are the basics (Name, author, version, etc). There will still most likely be some file for permissions and commands though.