[OUTDATED] Coming from Bukkit? Here's Some Tips and Tricks to Get you Started

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.

@DarkArcana Will this have a Java plugin like Bukkit? Or do we just put SpongeAPI in our build path?

Just import it to your classpath.

The best way to do this until there is a release (and the way it’s done by SpongeImpl) is

$ git submodule add https://github.com/SpongePowered/SpongeAPI
$ touch settings.gradle build.gradle
$ echo 'include "SpongeAPI" >> settings.gradle
$ tee -a build.gradle <<EOF
dependencies {
    compile project("SpongeAPI")
}
apply plugin: "java"
EOF

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

$ git submodule update --init --recursive

Is there already a JAR to program something or where do you know it?

@DAHumm3l There isn’t a jar ready yet. The repository can be viewed now though: GitHub - SpongePowered/SpongeAPI: A Minecraft plugin API It’s a work in progress.

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.

http://nexus.theyeticave.net/content/groups/public/

Maven dependency:

<repositories>
    <repository>
        <id>heroes-repo</id>
        <url>http://nexus.theyeticave.net/content/groups/public/</url>
    </repository>
</repositories>

<dependency>
  <groupId>org.spongepowered</groupId>
  <artifactId>SpongeAPI</artifactId>
  <version>1.0.0-SNAPSHOT</version>
</dependency>

For Gradle users in your build.gradle file (This will use the latest version, replace the + with 1.0.0-SNAPSHOT to use specific version):

buildscript {
    repositories {
        maven {
            name = 'heroes-repo'
            url = 'http://nexus.theyeticave.net/content/groups/public/'
       }
   }
   dependencies {
       classpath 'org.spongepowered:SpongeAPI:+'
   }
}
4 Likes

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…

No plugin.yml sounds excellent to me! That thing was always a pain.

Only thing it was a pain for really was commands and permissions, other than that I really liked having it :stuck_out_tongue:

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.

If it’s like forge, if you really wanted it, yes.

Forge AFAIK uses it’s own language by default.

Why not make a Sponge Wikia? Would be alot easier for server administrators to start-up their server.

Yours Sincerely,
Marijn van Wezel

1 Like

So current bukkit plugin won’t work? ;-; sigh If that’s the case. Time to contact the dev to see if we could get them recoded. -.-

I have some questions. And I am sorry if it is already answered.

First question: Where we have to put the .jar file of the plugin? in ./Plugins/, ./mods/ or …?

Second question: Is it possible to past Maven properties to plugin declaration? Something like:

@Plugin(id = "MyPlugin", name = "MyPlugin", version=${project.version})

or

@Plugin(id = "MyPlugin", name = "MyPlugin", version=getMavenAppProperties().getPropertyString("project.version"))

To answer your second question:

@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.

With Gradle that’s easy

@CurseLuke Tanks you for your answer

@simon816 (or someone else) Do you have a web link for gradle learning?

@Tabinol http://www.gradle.org/docs/current/userguide/userguide.html

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.