A "groovy" way to write plugins...

[Slugger]

I've just installed my first PoC build of a plugin completely written in Groovy. This may not excite many, but it sure excited me. While it's all fresh in my mind, I'm going to dump a few notes here about it. A complete wiki doc explaining all the details (and there really aren't many, actually) on how to do this is forthcoming.

Motivation: Be able to write plugins quickly, easily. Why Groovy? It's Java with a lot of the boilerplate code removed and a lot of "groovy" features added.

Requirements:

• 1) Your plugin must depend on the Groovy plugin, which is already in the repository
• 2) You must compile your Groovy scripts into Java bytecode so that the Sage core can consume your Groovy code

And that's really it. From there, you just write Groovy code and compile it into bytecode when your done. Once your groovy scripts are in bytecode form, it's really just Java as far as anything else (i.e. the Sage core) is concerned.

Why I wanted to try this: Combined with Sean's AbstractPlugin class from the sagex-api plugin, I can write plugin implementations in but a few lines of code. Here is the entire Groovy script of the plugin I'm working on.

package com.google.code.sagetvaddons.sop

import sage.SageTVPlugin
import sage.SageTVPluginRegistry
import sagex.api.Global
import sagex.plugin.AbstractPlugin
import sagex.plugin.SageEvent

final class Plugin extends AbstractPlugin {
	static final String PROP_PREFIX = 'sop_plugin/'
	static final String PROP_CLEAN_FREQ = PROP_PREFIX + 'clean_freq'
	
	private Timer timer
	
	Plugin(SageTVPluginRegistry reg) {
		super(reg)
		addProperty(SageTVPlugin.CONFIG_INTEGER, PROP_CLEAN_FREQ, '360', 'Cleaner Frequency (mins)', 'How often, in minutes, the cleaner thread will cleanup properties for non-existant objects.  Changes to this value require a plugin restart.')
	}
	
	@Override
	void start() {
		super.start()
		if(timer)
			timer.cancel()
		timer = new Timer(true)
		def freq = getConfigValue(PROP_CLEAN_FREQ).toInteger() * 60000
		timer.scheduleAtFixedRate(new TimerTask() {
			@Override
			void run() {
				DataStore.get().cleanup()
			}
		}, freq, freq)
	}
	
	@Override
	void stop() {
		super.stop()
		if(timer)
			timer.cancel()
		timer = null
	}
	
	@SageEvent("SystemMessagePosted")
	void handleEvent(String name, Map args) {
		Global.DebugLog("Event handled the Groovy way!")
	}
}

Except for a few missing semicolons and public declarations (public is default in Groovy), you might be thinking, "hey, that's no different than what the Java code would look like for the same thing!" You're right, but where Groovy really shines is in doing things like working with SQL:

This is my entire DataStore class, written in Groovy. Why I love Groovy for things like this:

• All the try/catch/finally blocks associated with JDBC code are removed; though a future refactor will probably end up doing some error checking, but it's not necessary in Groovy
• JDBC resource management is handled automatically by Groovy; no need to close result sets, statements, etc.
• Look how easy it is to play with rows from queries!
• Look how easy it is to work in transactions!
• It's just easier and quicker to write Groovy scripts for small plugins (like this one I'm working on)

package com.google.code.sagetvaddons.sop

import groovy.sql.Sql

import java.sql.Connection
import java.sql.PreparedStatement
import java.sql.SQLException

import sagex.api.AiringAPI
import sagex.api.ShowAPI

@PackageScope
final class DataStore {

	static private final DataStore INSTANCE = new DataStore()
	static final DataStore get() { return INSTANCE }

	Sql sql

	private DataStore() {
		initDb()
	}

	private void initDb() {
		sql = Sql.newInstance('jdbc:h2:tcp://localhost/plugins/sop/sop', 'admin', 'admin', 'org.h2.Driver')
		sql.execute 'CREATE TABLE IF NOT EXISTS airings (id INTEGER NOT NULL, key VARCHAR(255) NOT NULL, val LONGVARCHAR, PRIMARY KEY(id, key))'
		sql.execute 'CREATE TABLE IF NOT EXISTS shows (id VARCHAR(255) NOT NULL, key VARCHAR(255) NOT NULL, val LONGVARCHAR, PRIMARY KEY(id, key))'
	}

	boolean setAiringProperty(def airing, def key, def val) {
		def id = AiringAPI.GetAiringID(airing)
		sql.withTransaction {
			sql.execute "DELETE FROM airings WHERE id = $id"
			sql.execute "INSERT INTO airings (id, key, val) VALUES ($id, ${key.toString()}, ${val.toString()})"
		}
	}

	boolean setShowProperty(def show, def key, def val) {
		def id = ShowAPI.GetShowExternalID(show)
		sql.withTransaction {
			sql.execute "DELETE FROM shows WHERE id = $id"
			sql.execute "INSERT INTO shows (id, key, val) VALUES ($id, ${key.toString()}, ${val.toString()})"
		}
	}

	String getAiringProperty(def airing, def key, def defVal) {
		try {
			def row = sql.firstRow("SELECT val FROM airings WHERE id = ${AiringAPI.GetAiringID(airing)} AND key = ${key.toString()}")
			return row ? row[0].toString() : String.valueOf(defVal)
		} catch(SQLException e) {
			return String.valueOf(defVal)
		}
	}

	String getShowProperty(def show, def key, def defVal) {
		try {
			def row = sql.firstRow("SELECT val FROM shows WHERE id = ${ShowAPI.GetShowExternalID(show)} AND key = ${key.toString()}")
			return row ? row[0].toString() : String.valueOf(defVal)
		} catch(SQLException e) {
			return String.valueOf(defVal)
		}
	}
	
	void cleanup() {
		sql.withTransaction {
			sql.eachRow('SELECT id FROM airings') {
				if(!AiringAPI.GetAiringForID(it[0]))
					sql.execute("DELETE FROM airings WHERE id = ${it[0]}")
			}
		}
		
		sql.withTransaction {
			sql.eachRow('SELECT id FROM shows') {
				if(!ShowAPI.GetShowForExternalID(it[0]))
					sql.execute("DELETE FROM shows WHERE id = ${it[0]}")
			}
		}
	}
}

Try to implement this DataStore class in such a little amount of Java code!

As I say, I've actually installed this plugin on my test server and it's running happily so SageTV plugins written in Groovy is definitely a possibility! A wiki doc with a few more details is in the works and I'll post the link when it's done.

EDIT: Entire source code for plugin is here.

[PLUCKYHD]

Oh thanks for sharing definately peaked my interest.

[evilpenguin]

Well, of coarse, you had me at 'scripting'

Groovy's got some pretty robust webscraping libraries, I may have to play around with this

[stuckless]

That's very cool.

[evilpenguin]

I'm up and running with Groovy + Eclipse, any tips you want to share before I dive in?

[Slugger]

Originally Posted by evilpenguin

I'm up and running with Groovy + Eclipse, any tips you want to share before I dive in?

Not really, except for one tip: If you're not familiar with Groovy then take the time to learn and experiment on how to do things the "groovy way." I never even heard of Groovy until I started researching SJQv4 and my early script examples show that. My first Groovy scripts read almost like 100% Java then as you study my later examples over time you'll see I've started to learn the groovy way to do some things and then you really start to see it if you look at my plugin that I wrote (in my svn repository under trunk/sop). But then every day I play with Groovy I learn something new - there's lots of things to learn.

Two things I love that come to the top of my head as I write this:

Java:

// Check for string equality
if("FOO".equals(myvar)) { 
   // do whatever
}

Groovy:

if("FOO" == myvar) {
  // do whatever
}

They are both equivalent in Groovy, but the latter does not work (as intended) in Java, of course. I didn't even know of this for probably 2 or 3 months after I started with Groovy.

#2 Groovy thing off the top of my head: switch statements that work on any type:

def val = 'groovy'

switch(val) {
   case 'x': // whatever
   case 'y':
   default:
}

If you're switching on numbers you can even use ranges as a case, but I don't show that here because the exact syntax slips my mind.

Anyway, my point is that once you're comfortable with Groovy and learn some groovy shortcuts then I have no doubt plugin dev will be much, much quicker than doing the equivalent in Java, but there is some learning to do.

Note: Don't forget to depend on the groovy plugin to ensure your plugin users download and install the groovy runtime needed to run your groovy code. The current groovy plugin is at version 1.7.10. I intend to keep it there until I return to coding in the fall and then I'll probably upgrade to the recently released 1.8.0, which has a very groovy feature that finally allows the timing out of scripts automatically, but 1.7 -> 1.8 looks like too much of a change for me to be tackling over the summer.

[sdsean]

Groovy seems very very similar to JavaScript. . . and btw couldn't you do the same thing
with JavaScript itself?? You could just use the Rhino runtime, and then call various apis and what not. . . what does groovy give you specifically (besides just scripting, which I don't want to downplay. . is TOTALLY Cool).

[Slugger]

Groovy can be compiled to Java bytecode, which means that Sage can directly load Groovy code and run it as a plugin implementation class.

To use other languages, such as JavaScript, as a Sage plugin requires one of two things:

1) The language in use must compile directly to Java bytecode to be used directly by Sage as a plugin implementation class. To my knowledge, only Groovy supports this.

2) If your language of choice doesn't support #1 then you must write a Java wrapper that creates a JSR-223 script engine (or equivalent, depending on which language you want to use) in Java that then calls your scripts at runtime. This is certainly possible, but seems like a lot of overhead given that Groovy relieves you of all of these necessities.

In a nutshell, Groovy scripts can be compiled to Java bytecode and once they are then Sage sees them as nothing more than Java code that depends on the Groovy runtime jar file. This, to me, makes it the perfect candidate if you're looking at scripting for Sage plugins.