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


#62

That’s because both HOCON and YAML are supersets of JSON.


#63

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.


#64

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


#65

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

#66

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


#67

@DAHumm3l There isn’t a jar ready yet. The repository can be viewed now though: https://github.com/SpongePowered/SpongeAPI It’s a work in progress.


#68

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:+'
   }
}

We can't develop plugins, yet, can we?
#70

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…


#71

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


#72

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


#73

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.


#74

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


#75

Forge AFAIK uses it’s own language by default.


#76

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

Yours Sincerely,
Marijn van Wezel


#77

Why do we need Wikia?

Although its a good idea :slight_smile:


#78

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


#79

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"))

#80

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.


#81

With Gradle that’s easy


#82

@CurseLuke Tanks you for your answer

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