Sbt-spongyinfo - Easily create Sponge plugins using SBT


sbt-spongyinfo is a sbt plugin that makes making plugins for Sponge easier and less tedious, saving you time wondering why your plugin isn’t being detected correctly.

To add sbt-spongyinfo to your project, add this to your plugins.sbt

addSbtPlugin("net.katsstuff" % "sbt-spongyinfo" % "1.4")



  • Creates a dependency on on SpongeAPI automatically
  • Allows you to easily change the API version for a project
  • Automatically generates the file for you, based on information like the project id, name, version and so on.
  • Deploy your plugin to Ore from SBT


To just roll with the default settings, simply enable the plugin for the project, like so enablePlugins(SpongePlugin).

To set the Sponge version, use the key named spongeApiVersion. For example, to set the Sponge to 7.0.0, use spongeApiVersion := "7.0.0". The default is currently 7.0.0.

sbt-spongyinfo will try to use information it can find about the project to generate a sensible file. Given this project here:

lazy val mymod = (project in file(".")).enablePlugins(SpongePlugin).settings(
	scalaVersion := "2.11.8",
	name := "MyMod",
	version := "1.0",
	description := "An example project to show of sbt-spongyinfo",
	homepage := Some(url(""))

it will generate this file:

        "modid": "mymod",
        "name": "MyMod",
        "version": "1.0",
        "description": "An example project to show of sbt-spongyinfo",
        "url": ""

To set the information used to create the, use the key named spongePluginInfo. Example:

spongePluginInfo := PluginInfo(
  id               = "myplugin",
  name             = Some("MyPlugin"),
  version          = Some("9.9.999"),
  description      = Some("My special plugin"),
  url              = Some(""),
  authors          = Seq("Katrix"),
  dependencies     = Set(
      loadOrder = LoadOrder.None, 
      id = "myotherplugin", 
      version = Some("1.1.0"), 
      optional = false

All fields besides id are optional.

If you don’t want a file created for a project, for example if it is a shared project, you can easily specify this like this spongeMetaCreate := false.

If you want to manually create a file, run spongeMetaFile.


This is cool, but is there a way to make it parse the @Plugin annotation instead of the project file?

1 Like

Looked around a bunch, but haven’t found much. I know that you can get an Analysis back from compiling the project, but 1. not much documentation about how to use it. 2. From what I can see, if I do get something back, it’s most likely going to be the AST, so it’s going to be prone to breaking if the @Plugin annotation changes. 3. I’m a bit unsure if there might be downsides to generating the file that late. It might for example be that the resource generators always runs before compile.

I tried using sbt-buildinfo to do stuff the other way, however, you need the fields to be final, and you can’t make sbt-buildinfo
generate them as final. You are supposed to be able to change how it generates the file, however, it’s broken sadly.

1 Like

Wow, it’s been quite some time since I worked on this, anyway.

Version 1.1

  • Updated to SBT 1.x
  • Deploy plugins to Ore from SBT

How to deploy to Ore

First you need an deployment key. This can be generated by going to the settings of the project you want to deploy for. Then scroll down to Deployment Key, and click the button to generate a key.

Next you need to tell SBT about it. For the love of god, create a seperate sbt file where you only store the deployment key, and then add that file to your .gitignore. There are also a few other settings you can set from SBT documented below.

oreDeploymentKey := Some("<your key>")
//Set this if you want to change if the plugin should be recommended. Default is true
oreRecommended := false
//Change the channel that is put for your plugin. Default is `Release`
oreChannel := "Testing"
1 Like

Small updates this time

Version 1.2

  • Fixed some imports not being auto imports
  • oreDeploy is now an option, which means you can more easily disable it

Version 1.3

  • Integrates with sbt-crossproject to support cross building sponge plugins

As an example, if you had some code like this before

lazy val commonSettings = Seq(organization := "katrix", version := "0.1", scalaVersion := "2.12.4")

lazy val implSettings = Seq(name := s"MyPlugin-${spongeApiVersion.value}")

lazy val shared = project
  .settings(commonSettings: _*)
  .settings(name := "MyPlugin-shared", spongeMetaCreate := false, spongeApiVersion := "5.0.0")

lazy val v500 = project
  .settings(commonSettings, implSettings, spongeApiVersion := "5.0.0")

lazy val v600 = project
  .settings(commonSettings, implSettings, spongeApiVersion := "6.0.0")

It can now instead be written like this instead. This is also a true cross project. Meaning that the shared code is recompiled for each project.

lazy val myProject = crossProject(SpongePlatform("5.0.0"), SpongePlatform("6.0.0")).settings(
  name := s"MyPlugin-${spongeApiVersion.value}",
  organization := "katrix",
  version := "0.1",
  scalaVersion := "2.12.4"
lazy val myProjectV500 = myProject.spongeProject("5.0.0")
lazy val myProjectV600 = myProject.spongeProject("6.0.0")

For those that were around on Discord earlier today. Yes, this has everything to do with that.

Here’s a big one

Version 1.4

  • Added support for sending an changelog, and setting if a forum post should be created for Ore deploy task
  • Added support for sending files other than the assembly output for ore deploy
  • Updated sbt-crossproject
  • Added the ability to run plugins from sbt
  • Minor cleanup

Running plugins

sbt-spongyinfo now supports setting up a local server and running your plugins from within SBT. Both Forge and Vanilla are supported.

First you need to specify some versions information which will be used to fetch the server jars. The inner values that are wrapped in Option will become optional once Support querying by major API version · Issue #6 · SpongePowered/DownloadIndexer · GitHub is merged.

spongeForgeRunInfo in SpongeForge := Some(

spongeVanillaRunInfo in SpongeVanilla := Some(

Once that is done, just run SpongeForge/spongeRun or SpongeVanilla/spongeRun to launch the server. The tasks will do some setup the first time, you’ll have to accept the EULA, and then from there everything should be fine.

Both SpongeForge and SpongeVanilla extends the Runtime configuration, which means that if you want some other plugin on your server, just add it with that configuration.

There is also experimental support for depending on plugins from Ore (only reviewed plugins for now) using oreDependency.

Using all of the above, you could do libraryDependencies += oreDependency("katlib", "2.1.0") % Runtime to add the KatLib plugin to your enviroment when running the server.