mBrainSpace

simple-x

noreply@blogger.com (matt) — Mon, 07 Mar 2011 09:17:00 +0000

Apologies for the short hiatus from blogging here, but I was pretty busy with moving country and all. Hauling your butt across the european continent and back to blightly is a mighty stressful affair, I can tell you!

Anyway, I started plugging away at a small project some of you might be interested in. Inspired by XStream and my mud, I've written a spin off project that could be quite useful. I wrote it in plain Java but tested it with Groovy, which was fun :)

Simple-x is a small fast xml database like ORM tool that allows you to persist an object tree easily. The objects you wish to keep track of can be given an ID annotated field and loaded independently from their parents. You can even lazyload fields with the lazyload annotation. It persists the xml in a directory of your choice, as one file per Id allocated object, much like a FilePersistentStrategy would do but with bells on (no separate collection classes for example).

I wrote it mainly because I was tired of ORM tools being configuration heavy, and having to specify joins in complicated xml or other files and didn't want to have all that heavy lifting to do.

An example of how to use it:


import org.corbym.simplex.persistence.annotations.Id
...
class SomeObjectWithId(){
    @Id
    def id
}
...
class SomeObjectWithDefFieldAndId{
    @Id
    def id
    def somefield
}
...
final idObject = new SomeObjectWithId()
final someObject = new SomeObjectWithDefFieldAndId(somefield: ["thingy": idObject])
someObject.somefield.put "thing2", new SomeObjectWithoutId()
SimplexDao dao = SimplexDaoFactory.getInstance()

dao.save(someObject)

assert someObject.id != null
assert idObject.id != null

def loaded = dao.load(SomeObjectWithId, idObject.id)
assert loaded, "object should be loaded but was $loaded"

def otherThatContainedIdObject = dao.load(SomeObjectWithDefFieldAndId, someObject.id)
assert otherThatContainedIdObject.somefield.values().size() == 2

It's a little incomplete, requires lazyloadable collections and needs a decent caching implementation to prevent slowness but it works ok.

Maven Pom Transformer

noreply@blogger.com (matt) — Tue, 11 May 2010 11:34:00 +0000

So Craig Tataryn asked about why we were having maven problems, and wanted to know more info. So here it is :)

Maven is overly strict with version numbers. The release plugin expects either numbers or alphas, but not both, with or without the -SNAPSHOT extension. Another problem is that release:prepare does not change plugin configuration if it depends on a version thats being built in the reactor build.

Maven plugins can be buggy at the best of times so I prefer to do this stuff myself anyway ;)

With all that in mind, I took to Groovy to solve my problems. Firstly, I needed a class to hold my pom data:



package branch.modify.transform


import java.io.File;


class PomData{
 def root
 File pomFile
 String artifactId
 String groupId 
 boolean persistFile
}

... and then I went on to use DOMCategory to create this little beauty:


class PomTransformer {
 
 def skipDirectories = ['.svn', 'src', '.metadata']
 
 def updateDependencies = { findIn, pomData, newValue ->
  println "updating dependencies for ${pomData.artifactId}, ${pomData.groupId}"
  use(DOMCategory){
   pomData.root.'**'.findAll {
    (it.artifactId.text()  == findIn.artifactId && it.groupId.text() == findIn.groupId)    
    
   }.each{   
    pomData.persistFile = changeVersion(it.version, newValue, pomData.persistFile)    
   }
  }
  return pomData
 }
 
 def transform(workingDirectory, version){
  File startDir = new File(workingDirectory)
  assert "File is not a directory", startDir.isDirectory()
  List pomList = []
  
  startDir.eachFileRecurse { File file -> 
   if(file.isDirectory() && skipDirectories.any{ it == file.name } ){
    return
   }
   if(file.name == "pom.xml"){
    println "reading file ${file.path}"
    def doc = DOMBuilder.parse(new FileReader(file))
    def project = doc.documentElement
    use(DOMCategory){
     def artifact = project.artifactId[0]?.text()
     def group = project.groupId[0]?.text()
     println "adding group $group and artifact $artifact to list"
     PomData data = new PomData(root: project, artifactId:artifact, groupId: group, pomFile: file)
     pomList.add(data)
    }
   }                     
  }
  
  replaceValues(pomList, version)
  for (PomData it : pomList) {
   File f = new File(it.pomFile.path).asWritable()
   if(f.canWrite() && it.persistFile){
    String xml = XmlUtil.serialize(it.root)
    println "writing $f.path"
    f.write(xml)
   }else{
    println "${it.persistFile ? 'cannot' : 'no version change, not going to'} write to file ${f.path}"
   }
  }
 }
 

 
 def replaceValues(list, ver){
  use(DOMCategory){
   new ArrayList(list).each{    
    
    it.persistFile = changeVersion(it.root.version, ver, it.persistFile)
    new ArrayList(list).each{ data ->     
     updateDependencies(it, data, ver) // update dependencies in other poms
    }
    
   }
  }
 }
 def changeVersion(versionElements, ver, persistFile){
  if(!versionElements){
   println "no element found"
   return
  }
  persistFile = ((versionElements[0]?.text() != ver) || persistFile)  
  if(persistFile){
   versionElements[0]?.value = ver 
  }
  return persistFile
 }
}

Firstly, you obviously need to check out your dependent projects into a folder. I am assuming here that each project you check out is part of a multi-module build, and that each project is in some way dependent on the others.

To run the transformer, call "transform" with the working directory (the folder you checked all the projects out in to), and a version (such as 3.1.2-SNAPSHOT). Transform moves through the entire workspace directory by directory, and gathers the poms it needs to change in a list.

Once it has gathered these, it calls replaceValues. This method goes through each of the gathered poms and changes the version in that pom file, and also any reference to the same module in the other pom files in any element it finds.

The only thing this does not do is change any scm information, which it can be modified to do but I have not done (yet) - I do it another more convoluted way.

Hope this is useful :)

Hudson Build Times

noreply@blogger.com (matt) — Sun, 09 May 2010 17:21:00 +0000

So we use Hudson at work to build stuff.

I've got it branching all our projects with a branch build using groovy, and because Maven doesn't work properly for us, updating all the project pom versions as well. I'll save that for a another time, the code is fairly in depth.

The branch scripts also create a build in Hudson too, with this little nugget:


package my.package

import groovy.text.GStringTemplateEngine;
import org.apache.commons.httpclient.*
import org.apache.commons.httpclient.auth.*
import org.apache.commons.httpclient.methods.*

import java.net.URLEncoder;

@Grab(group='commons-httpclient', module='commons-httpclient', version='3.1')
class HudsonBuildCreator {
   def server = "build"
   def hudsonHost = "http://${server}:8080"
 
   def username = "username"
   def password = "password"
   
   def createBuild(String projectName, String svnUrl){
       println "Creating hudson build..."
       def client = new HttpClient()
       client.state.setCredentials(
          new AuthScope( server, 8080, "realm"),
          new UsernamePasswordCredentials( username, password )
       )
       client.params.authenticationPreemptive = true
       projectName = URLEncoder.encode(projectName)
       String postString = "${hudsonHost}/createItem?name=${projectName}"
       println "creating post method to ${postString}"
       def post = new PostMethod( postString )
       post.doAuthentication = true
       String file = this.getClass().getResource("/my/package/config.template").getFile()
       println "loading $file template"
       File input = new File(file)
       def engine = new GStringTemplateEngine()
       def binding = ["svnUrl": "$svnUrl"]
       def template = engine.createTemplate(input).make(binding)
  
       def xml = template.toString()
       println "sending: \n $xml"
       RequestEntity entity = new StringRequestEntity(xml, "application/xml", "UTF-8");
       post.setRequestEntity(entity);
       try {
           int result = client.executeMethod(post)
           println "Return code: ${result}"
           post.responseHeaders.each{ println it.toString().trim() }
           assert result == 200, "$result, failed"
           post.responseHeaders.each{ println it.toString().trim() }
           println post.getResponseBodyAsString()
       } finally {
           post.releaseConnection()
       }
       println "Done creating Hudson build."
     
   }
}

This calls the Hudson API and posts some xml to it to create a new build. I wanted it to be called from outside the Hudson environment too, so that it could be run from one of the dev's local machines without them having to log in to hudson.

The xml sent to Hudson is a copy of the xml you can find in the api, with some GroovyTemplate coolness added to it so I can specify the build svn url (held in the svnUrl variable). You can find the xml in the following location:

http://[my build server}/job/[job name]/config.xml

Just take that, create a resource with it (copy it into the same package as the groovy class) and call it "config.template".

One thing that was left was to space out my newly created builds. Surfing around the Hudson wiki pages I found something that displayed all the build trigger specs (the objects which take a cron tab like string) that let you specify the time the build is triggered. I wanted to update these, spaced out by 15 minutes or so, and came up with this:



import hudson.model.*
import hudson.triggers.*


int hourMax = 23 // could be 8, for 8am, before everyone comes in... 
int minMax = 59
int incr = 15
int hr = 0
int m = 0


for(item in Hudson.instance.items) {
    item.triggers.each{ descriptor, trigger ->
        if(trigger instanceof TimerTrigger) {
            println("--- Timer trigger for " + item.name + " ---")
            println(trigger.spec + '\n')
            if(item.name != "merge-process"){
                item.removeTrigger descriptor
                item.save()
                item.addTrigger(new TimerTrigger("$m $hr * * *"))
                item.save()
                println "updated to $m $hr * * *"
                m += incr
            }
                       
            
            if(m > minMax){ hr++; m = 0}
            if(hr > hourMax) { hr = 0; }
        }
    }
}

I run this as a separate build to the branch and merge scripts, triggered from the branch build, as a freestyle project that's sole responsibility is to run a system groovy script.

The output looks like this:


Started by user admin

bug-fix-1
--- Timer trigger for bug-fix-1 ---
@midnight

updated to 0 0 * * *
--- Timer trigger for change-batch-1 ---
@midnight

updated to 15 0 * * *
Finished: SUCCESS

Neat :)

NB you will need the Groovy plugin for Hudson to run the system Groovy script, and also have Groovy installed on your build server.

WHOOPS: This, although it seems to work on the surface, fails to trigger the builds once they have been updated. I will post why this might be soon... possibly a hudson bug or something I haven't done?

groovy workplace 2

noreply@blogger.com (matt) — Sat, 20 Feb 2010 15:10:00 +0000

Well, I've finished development on my Groovy branch and merge scripts for work. I'm quite please with the result: I can now run a Hudson build which runs my groovy scripts whenever I need them. Developers can also check the project out of svn and run them with command line parameters.

I've even done a parameterized build for the branching script in Hudson, so developers and admins can create their own branch from there. Next step is to enable the branch script to create a build in Hudson, but I'm not sure how best to go about this: I expect I can access the Hudson instance from groovy but I'm not sure of the correct methods to call, or I could do it using an HTTP call to Hudson with parameters. Either way, I'm pretty happy with it all, and the best thing about it is that its Unit Tested and they run before any branch or merge happens :)

When the developer checked out the script, I felt having to add the classpath everytime they ran the script was a bit much. The only thing I had a problem with was making the command line call easy to use.

The basic premise to solve the problem was to use a class loader. This is the price I had to pay for using a shebang. Shebangs can only take one parameter, and the groovy start app requires two; one for the "-cp" and one for the actual classpath you send. So I created a special ClassPathHelper class to help find the relative location of the script to the file system, in the same directory as the scripts I want to run:


import java.net.URI;
import java.net.URL;

class ClassPathHelper {
 
 static def include(caller, packageName){ 
  def url = new File(new File(caller.getClass().protectionDomain.codeSource.location.path).parent + "/$packageName/") // protectionDomain.codeSource.location.path may not exist in compiled groovy classes..
  caller.getClass().classLoader.rootLoader.addURL(url.toURI().toURL())
 }
}

Then all you need to do then is to "include" your dependent directories:


#!/usr/bin/env groovy

import static ClassPathHelper.include 

include(this, "../src/main/groovy") // include the directory above in the classpath

include(this, "../lib/foo.jar") // include a jar in lib directory (could use grape)

classLoader = this.getClass().classLoader

ProcessHandler = classLoader.loadClass("com.vcint.process.ProcessHandler")
// .. rest of script

Despite the documentation saying that you should use Class.forName, this does not always work because (according to Jochen) forName "does some stack tricks to find the right class loader, tricks that won't always work with Groovy" (thanks, Jochen :)

Partial (Half) mocks: Why they're good - a real world example

noreply@blogger.com (matt) — Wed, 10 Feb 2010 12:16:00 +0000

Following up from the post on DZone, I found a use case for the "half mock" approach they discuss here that relates to a real life problem.

Currently I'm creating a groovy app that runs a lot of command line processes and processes their results. Unit testing for the usual:


...
   def output = "ls -lart".execute().text
   println output.length()
...

... is a little tricky to say the least. This is because the object that you are calling execute on is a string and is effectively this code:


    def output = new String("ls -lart").execute().text
    println output.length()

One option is to create a delegate to actually execute the command and return the Process object. But that's not very groovy. Another is to use MockFor:


  def bArray = "Hello World".getBytes();
  def stream = new ByteArrayInputStream(bArray);
 
  def mockProcess = [getInputStream : {stream}] as Process
  def myMockString = new MockFor(String)
  myMockString.demand.execute {
       return mockProcess
  }

.. but in 1.7.0, this also mocks out all the other calls String, on any instance of String anywhere in the method. The method length() on the string will say there is no demand for "length", when actually we really need the string returned from the mock process to behave like a real string. We could add "demand.length" to the mockFor String, but if we have many cases where strings are used there could be very annoying to catch all the cases, especially if we are trying to process the string in any way.

With partial mocks, we can do this:


  byte[] bArray = "Hello World".getBytes();
  def stream = new ByteArrayInputStream(bArray);
 
  def mockProcess = [getInputStream : {stream}] as Process

  def myMockString = new MockFor(String)
  myMockString.ignore(~'get.*')  // don't mock any getters
  myMockString.ignore(~'length.*') // don't mock String.length()

  myMockString.demand.execute {
       return mockProcess
  }

This is obviously a contrived example, but it's applications are deep... pretty groovy stuff :)

Mocking File splitEachLine

noreply@blogger.com (matt) — Wed, 10 Feb 2010 10:32:00 +0000

I thought I'd share this tip. I was trying to mock the behaviour of a file read, each line being read in and processed by a closure in the normal way:


class MyFileReader{
    def myFileRead(){
        def file = new File(myFile)
        file.splitEachLine(","){ tokens ->
            println token[0]
            println token[1]
        }
    }
}

splitEachLine is a closure call attached to the file, which actually invokes the DefaultGroovyMethods static method splitEachLine(File self, String regex, Closure closure) . I could just mock the call to splitEachLine on the File object, but I also really want to be able to test my closure functionality as well without extracting the closure contents to another method.

Here's how I managed to mock it:


def fileText = """\
col1, col2
col1a, col2a
"""

def mockFile = new MockFor(File)
mockFile.demand.splitEachLine { sep, Closure c ->
    Reader stringReader = new StringReader(fileText)
    DefaultGroovyMethods.splitEachLine(stringReader as Reader, sep, c)
}

mockFile.use{
    new MyFileReader.myFileRead()
}

Now on the surface this may not look that useful, I'm not actually testing anything in that example. But looking deeper what it has done is given me the control to pass in my own set of mock text to the splitEachLine closure, rather than having groovy read a real file. Methods called by that closure can now be tested against that data, which is a huge benefit.

groovy workplace

noreply@blogger.com (matt) — Fri, 05 Feb 2010 19:45:00 +0000

Finally, I am using groovy at work ;)

I am writing a merge script to perform custom svn merges from branch to branch, and the plan is to run it from hudson :)

I found someone had thought of doing this before and even produced some google code hosted code for it, but it's a bit too bloated for me and only merges code into trunk.. also the author seems to have got distracted building a cli argument parser, which groovy already has ...

At last!! Yay!

dynamic SQL statements

noreply@blogger.com (matt) — Thu, 04 Feb 2010 09:55:00 +0000

Now, I know it's not good practice to inject unchecked parameters into an sql with strings. Especially input from users.

But if you are processing a list of unknown size and just Do Not Have Time(tm), you need to create a statement where you have a variable number of inputs.

This can be tricky in java, building strings is a pain in the arse.

However, with groovy it's a breeze. In our example, we are taking a csv file, reading it in and selecting data from a db with the values received:


import java.sql.Connection;

import java.sql.DriverManager;
import java.sql.SQLException;

def list = []
def stream = getClass().getResourceAsStream("failed.csv"); // or use a file
(stream.getText()).splitEachLine(',') {fields ->
 if(!fields[0].toString().trim().isEmpty()){
  list.add fields[0]
 }
}
Connection connection = DriverManager.getConnection("jdbc:Oracle:thin:username/password@xyz:1521:abc");
Sql sql = new Sql(connection);

def query = "select * from foo where id in (${'?, '*(list.size()-1)}?)"
sql.query query, list, {ResultSet rs ->
    println rs.getLong("id"); // and other stuff from foo
}
sql.close()

The magic groovy fu here is generating a list of question marks inside the select statment:


${('? ,' * (list.size()-1)}?

Grokking this may seem tricky, but actually it's fairly simple. The GString parameter ${} is being told to create '?, ' as many times (*) as list has elements less one (list.size() - 1) and append a ? at the end to make up for the last parameter. Easy eh?

NOTE: I do not condone this way as general use, just as a quick n dirty hack. Generally, this sort of query will execute slowly and annoy dba's. Often a query will run a lot faster if you create a temporary table and insert all the values into it first.

Also note, this will not work on some databases (for example, Oracle) if the list size exceeds a certain number. For any more than around 1000 values you really should use a temporary table...

Groovy 2

noreply@blogger.com (matt) — Wed, 03 Feb 2010 21:48:00 +0000

I love the open source community ..No sooner had I entered my request for a new Groovy feature, Guillaume Laforge adds it to the new MOP requirements for Groovy 2 :)

The main problem is that you cannot persist metaclass closures. For example:


def object = new MyObjectBase()
object.metaClass.doSomething = { println "hello groovy world!" }
object.doSomething() // prints hello etc
def xstream = new XStream()
xstream.classLoader = getClass().classLoader
new File("object.xml").withOutputStream { out ->
    xstream.toXML(object, out)
}

new File("object.xml").withInputStream { ins ->
    object = xstream.fromXML(ins)
}
object.doSomething() // throws an exception :(

... the closure has not been restored. Which sort of sucks. Shame I have to wait for Groovy 2 tho :(

Anyhew, I've been away for a while due to personal circumstances, but I hope to regain the enthusiasm for Groovy I had just before my last post.

Onward, to greater groovier things!!

Grapes of Wrath

noreply@blogger.com (matt) — Fri, 04 Sep 2009 09:24:00 +0000

Groovy Grape comes standard now with Groovy 1.6.x. I am not going to go in to what Grape is for in this article, but suffice to say think of a dynamic, runtime version of Maven.

I was trying to set up a Groovy run script that would download and run my application using Grapes, but hit on a problem that some of you might find useful to know about: When I tried to instantiate one of my classes from the run script, it could not find the class' dependencies.

This is a bit of a doozy. When I searched Jira about a bug, I came across this issue. In my own script it was a bit more complex than this, but suffice to say the issues were the same. I will use the example from Jira to explain what is happening. Consider this code:


import groovy.sql.Sql;
import groovy.grape.Grape;


Grape.grab(group:'mysql', module:'mysql-connector-java', version:'5.1.6' )

def sql=Sql.newInstance("jdbc:mysql://localhost/test","root","",
"com.mysql.jdbc.Driver");

println sql.firstRow("SELECT now( )");

This will fail with a ClassNotFoundException. But why?

Let me try to explain about what's going on here. Grape resolves and adds the dependencies to the current classes classloader, and classloaders work in tree formations. Classloaders further up the tree cannot see dependencies further down (or on different "branches").It turns out the SQL static newInstance method uses a different classloader higher up the tree from the run script.

You can check this by printing the dependencies on the current and system classloaders by passing them to the listDependencies method of Grape:


println Grape.listDependencies(ClassLoader.systemClassLoader)
println Grape.listDependencies(this.class.classLoader)

The first is empty, the second has all your dependencies.

So how do we work round this? The Grab method allows you to specify the classLoader to use for adding the dependencies on:


import groovy.sql.Sql;
import groovy.grape.Grape;


Grape.grab(group:'mysql', module:'mysql-connector-java', version:'5.1.6', classLoader:ClassLoader.systemClassLoader)


def sql=Sql.newInstance("jdbc:mysql://localhost/test","root","", "com.mysql.jdbc.Driver");

println sql.firstRow("SELECT now( )");

Thanks to Mr Haki (see the comments below) for the correct solution!

Building a VI clone with Groovy pt 2

noreply@blogger.com (matt) — Wed, 19 Aug 2009 11:26:00 +0000

Ok so, here's the beef. My main issue at the moment with my vi clone is that I think my assumptions about the way I was using a StringBuilder* were initially incorrect. I actually think I now need to store each line separately in a list. This way, I can keep track of the caret, and know exactly which line I am on as well:


def buffers = new File(argstr).getText().tokenize('\n').collect{ new StringBuilder(it) }

With that sorted, I find myself with a number of requirements:

Moving the cursor should be done with the arrow keys.
Deleting stuff (x) should remove the character at the right x, y position.
Do not pass the screen boundary, scroll the file down.
When at the end of the file, do not move the cursor further.
When I am in append mode, text should be added to the end of the line no matter where in the line I am. The cursor should be moved as well.
When I hit escape, a number of things can happen: If I am in edit mode, I drop back to movement mode; If I am in movement mode, I leave the editor (for now, saving the file will be automatic, rather than explicit for simplicity).
If I am in Append Mode or in Edit Mode I should be able to type text in to the correct buffer, and have it appear on my screen. Also, pressing enter should move on to a new line inbetween the current line and the next.
Do not wrap text on the screen for the time being.

Requirement eight I am a little reticent about. I am not sure if it would be harder to work out whether we have wrapped the text on a line (could be stored as a boolean on an object wrapping the StringBuilder) or whether it is better to scroll the whole file with the cursor at the screen boundary. I guess both are valid solutions, and in the future the user could be given an option to do either.

Encapsulating the StringBuilder in a decorator class of it's own does make sense though, because I might be able to add extra information to the line (like, last know caret position) as well as whether it has wrapped or not. I realise that the string length could be calculated every time to work this out, but encapsulating this functionality would be better I feel.

* I have switched to StringBuilder because I forgot I was using Java 5 :O

*

Persisting class with metaclass

noreply@blogger.com (matt) — Sun, 16 Aug 2009 07:40:00 +0000

The metaclass object on a Groovy object is marked transient, and with good reasons: I don't event want to think about actually persisting the entire thing.

However, I'd like to be able to persist closures that belong to the class, since I spent the energy actually scripting the additional methods I would like them to be loaded when I need them?

Has anyone got any clues?

GREclipse Plugin V2

noreply@blogger.com (matt) — Thu, 13 Aug 2009 14:40:00 +0000

Before I forget, I really aught to plug version 2 of the GREclipse plugin. It is far far superior to the old one, and I entirely recommend updating to it.

Gone are the silly builders and having to have the output on your classpath woes, V2 does some very good things to make up for all the awfulness of the old one. JUnit tests run like a breeze, and although buggy, code completion is there.

If you are using the old one, uninstall it first and get rid of any fluff on the classpath. Something else to watch out for is that you might need to uncheck the Groovy Libraries entry on the "order and export" tab on the project's preferences.

Check it out, I highly recommend it as a replacement.

Building a VI clone with Groovy

noreply@blogger.com (matt) — Mon, 10 Aug 2009 20:20:00 +0000

The great thing about online spaces is they tend to be able to build themselves. Give enough decent tools for the users of a space, and they can make some kickass things. And bizarre things too. And very very garish things :(

Anyway, MUDS also allow this sort of thing, but in a more controlled fashion. MUDS generally have some sort of hierarchy to prevent the idiots from changing bits of the game that are really cool and ruining it for others. Called "creators", these hand picked super users can change parts of the game to make it more exciting, add depth and new content as often as required.

So I need some tools for the creators in my MUD to go about editing the groovy scripts and other files. Which brings me to the problem: there are no telnet based text editors written in either Java or Groovy that can do this. Guess I'll have to build my own? GroovyMud already has a command loop type shell implementation, but adding an entire shell for this sort of thing is a little overkill. With GroovyMud I am able to run scripts as commands (remember last time?) in the MUD by just typing the name, and the CommandInterpreter invokes the GroovyScriptEngine to run it. I can leverage this behaviour nicely :D

I will be logging my progress in creating this editor here when I can, so keep tuned to find out how I get on.

So to start, I struck on having a vi type editor for the interface. For those of you not familiar with vi, (get out now!! :D just kidding), it is a very simple *nix text editor with a lot of very cool functions. There are no menus, just a number of commands that can put you into different states in order to do stuff with the text.

For example, start up vi and push "i", and you enter "input" mode. Enter characters to add text to the file, and then push escape. You return back to movement mode, where you can move around the text file using the arrow keys. In movement mode, you can not only move the caret around, but delete characters with 'x' and lines by pressing 'd' and 'd' again. The default mode is movement, so you can move to where ever you need to add stuff in your file.

So an enum for these states would be useful, with our default:


   enum Mode {
 INSERT, APPEND, MOVE
   }
   Mode currentMode = Mode.MOVE

Obviously we would also need to store the position of our caret in the text file, so Groovy's StringBuffer and file manipulation api extensions should help me here:


   int xPos = 0
   int yPos = 0

   StringBuffer fileContents = new StringBuffer(new File(argstr).getText())

In GroovyMud land, the player that is performing the edit is passed into the script as a paramter called "source". They have a very nice handy telnet ExtendedTerminalIO object to play with, which for these purposes acts just like any other kind of stream (except I can read lines with it with readln). So I can get a handle on this to manipulate their IOStream to their telnet prompt like this:


ExtendedTerminalIO stream = source.terminalOutput
stream.eraseToBeginOfScreen() // nifty function to clear the screen
stream.write(fileContents) // write out the file contents
stream.moveCursor(xPos, yPos)  // move the cursor to the beginning of the file.

This is good, I now have a screen full of file with my cursor at the start. But how would I work within the framework of the script to provide the command interface? Then I hit on the idea of using a map to hold the actions for each key press:


def commandMap = ["i": {currentMode = INSERT}, 
                  "a" : {currentMode = APPEND},
                  "x" : { ... perform some delete function ...},
                  
                 ]

Ok so far so good. We also need some kind of input loop, to trap the users input until we exit. So setting up a while loop here would probably be a good thing:


boolean exit = false

while(!exit){
 char ch = stream.read()
 //perform the command in the map first
}

Ok this is as far as I have got. In theory I should be able to call the command in the map with the character that I read in. The closures there will handle the movement of the caret, the deletion of the chars in the string and any other functions, depending on the MODE I am in. I also want to add more funky stuff too, like code completion, colourization and other stuff like that.

More next time.

another bug bites the dust

noreply@blogger.com (matt) — Wed, 22 Jul 2009 18:21:00 +0000

Another beauty of a bug bites the dust in Groovy 1.7-beta-1: GroovyScriptEngine fails to load mutually dependant classes.

This had been a big pain for me in the past, because I would have to watch out how I wrote my code. In the beginning, I hadn't got rid of the habit of statically typing my data, so doing something like this:


IBar.groovy:

package test

import test.Foo

public interface IBar{
    public void doStuff(Foo foo);
}

Foo.groovy:

package test

import test.IBar;

public class Foo{
    public void doSomeFoo(IBar obj){
        out.print("foo!");
    }
}

... and use the GSE to load one of the objects, things would fail with an infinite lookup loop.

Now I hardly use interfaces its not such a problem, but it's still good to get it fixed. My thanks to Jochen (again ;))

Bottled it.. why?

noreply@blogger.com (matt) — Wed, 08 Jul 2009 09:43:00 +0000

Darn...

I had the perfect opportunity to use Groovy today on a work project. And I bottled it.

Why? I love Groovy. It's useful, concise and powerful. Yet here I am, slogging away at the solution in Java, and cursing every time I have to put a semicolon in.

I've been wanting to use Groovy for a long time now in my day job. I have had my reservations. These are mainly to do with:

1. No one else in my department understands Groovy
2. The architect has expressed reservations about it (well, not so much about Groovy as implementing new things without training)
3. Even though I was using the maven plugin to generate my project, I had reservations about how I would go about deploying it.
4. Mainly, I was confused about whether it really needed to be Groovy or not.

These things panicked me, and I lost my bottle. Maybe next time... :(

Stringy Lists and Maps

noreply@blogger.com (matt) — Wed, 01 Jul 2009 07:22:00 +0000

We all like to keep lists and maps of our objects. From shopping lists to translation maps, these useful little utilities are the staple diet of any Java programmer.

You need to be careful with lists and maps when using GStrings. Consider the following test:


public class GroovyTest extends GroovyTestCase{
 
 void testAddName(){  
  def name = "tom"
  def someNames = []
  
  someNames.add("${name} 1")
  
  assertTrue someNames.contains("tom 1")
 }
}

This test will fail. But why? Well, the GString "${name}" and the GString "tom 1" are different object types. "tom 1" is a String, and "${name} 1" is a GString.

Something similar happens with maps, when using a GString as a key. This time it is the hashcode of the GString which is different each time.

As Jochen puts it on JIRA :

"there where several discussion on the mailing list for the usage of GStrings as map keys. Map keys things that should keep their hashcode the same and their euqals(sic) method should also return always the same if feed with the same object. This implies that hash key objects should either not be changed or even better, they should not be mutable. GStrings are mutable. Making a map immutable, does not change that fact. And while the GString "${p}" or "$p" uses the value of p at the time the GString was created and thus could be seen as something that does not change, the GString "${>p}" uses a closure and evaluates the value of p every time anew. Not only that, but the hashcode of "${>p}" differs from "$p", because the hashcode of the closure is used, instead of the hashcode of p to create the GString's hashcode.

So I suggest you to just follow the rule to nether to use a GString as key and there is no issue at all. Even the GString "$p" and "33" do not have the same hashcode for p=33. That is no bug, that is a design decision often discussed on the list. But there are good reasons for it. "

So, how do we work around these problems? Well, there is no elegant solution to this but calling toString on the GString should at least solve some of it:


public class GroovyTest extends GroovyTestCase{
 
 void testAddName(){  
  def name = "tom"
  def someNames = []
  
  someNames.add("${name} 1".toString())
  
  assertTrue someNames.contains('tom 1') // note we can also switch to single quotes?
 }
}

... at least our test now passes. The same solution would work for keys on maps.

Has anyone got a more elegant solution to this?

Lets Interface

noreply@blogger.com (matt) — Mon, 08 Jun 2009 07:01:00 +0000

Java and Groovy work seemlessly together. Or at least thats the idea. However there are some tricky concepts as a Java programmer you might need to know about interfaces and Groovy. By interface, I do not always mean the interface declaration (as in "interface foo { void bar();} - although this does include that). I mean method declarations, constructors and getters and setters.

Groovy can be softly typed, whilst Java likes things strongly typed. As a Java programmer I found it quite tricky to get my head around. I wanted to make everything softly typed in groovy (because I wanted to be, you know, Groovier man), and when it came to interfaces I couldn't reconcile the two ideas. Without the compiler to tell me I was bodging things up, I would try to program around the issues.

Here are some gotchas and insights to remember when dealing with interfaces.

1. When implementing an interface, the keyword def might not work how you think

The keyword "def" does not mean "any object type". Groovy does not take the def type to mean literally any type, it means "any Object type or (groovy) void type". The compiler will moan if you try to implement interface methods defined with the def keyword instead of the String keyword for example.

Conversely if an interface defines "Object" as its type, you CAN define the method with def in Groovy (but not other types like String).

GOTCHA: Although you cannot use def to declare concrete methods where the interface method is declared void, you can use void to declare concrete groovy object methods that are typed as "def" in your interface. E.g:


// this is ok...
interface Wombat{
 def foo();
}

public class InterfaceTest implements Wombat{

 void foo(){
  println("hey")
 }
 
}

however...

 
// this is NOT ok
interface Wombat{
 void foo();
}


public class InterfaceTest implements Wombat{

 def foo(){
  println("hey")
 }
 
}

2. Automatic getters and setters only work with interfaces if they are declared with the same type

If you have a required getter and setter pairing, for say Spring or Javabeans declaration, automatic getters and setters will only work if the property has exactly the same type.

This is related to number 1, because believing "def" can define a String type is incorrect (although you can HOLD a String type in a def type object, it is not the same as expecting a return of type String).

3. Groovy automated constructors call your setter methods.

In groovy, a.name = "brian" is the same as a.setName("brian"), so you would think this one would be rather obvious. But because I'm used to setting properties directly in a constructor rather than calling setters, I have been gotcha'd by this one several times. I originally thought that an automatic constructor would do a.@name = "brian" but it does not, and if you put any logic into your setProperty or setName method it will always get called when the object is constructed and could be the cause of many NullPointerExceptions!

4. Constructor argument order matters!

This is related to 3. The order of your automatic constructor arguments actually matters.

Say you have constructor a with arguments x y and z. If a setter of z uses x to perform a check and x depends on y to exist, then you must construct the object with arguments to reflect this.

For the object to be constructed properly you must put them in dependency order from none to most, left to right, like this:


def groovyObject = new GroovyObject(x, y, z) // x depends on y and z depends on both

5.GStrings are NOT Strings

This one doesn't seem interface related, but as I was explaining before in Stringy G-Strings when a GString hits an interface boundary, you can expect it to be evaluated if the boundary type is String and not def or GString.

Don't go around thinking you can pass GStrings around easily. At some point, someone somewhere may be expecting a String, and so as soon as the "toString" method is called on the GString, it will be evaluated within the scope of the calling method and could cause errors. Even lazy GStrings can be problematic.

[edit to correct my definition of def - see, its very confusing!!]

Creating a MOB DSL

noreply@blogger.com (matt) — Thu, 04 Jun 2009 08:33:00 +0000

Muds have something called MOBs. No one really knows what MOB stands for but my guess is MObile Object or some such.

MOBs inhabit a MUD and can interact with the user, move about, talk and perform every action that a player can.

Since the beginning of muds, programmers have created languages that make non-player characters behave the way they want them to. One of these languages is called MOBProg which you can specify actions for a mob in a simple sequence:


... mob prog stuff to define the mob ..
>greet_prog 100~
  if ispc($n)
    mpadd mpecho $I says, ‘Get out of my way!! GRRR!!!’
    mpadd kill $n
  else
    endif
  endif

~

This is part behavioural and part MOB instruction - if the player is a Player Character (pc), add the echo command for the mob to say "get out of my way" and then kill the pc.

Because Groovy has the ability to create DSLs, this is a natural way to go. GroovyMud uses the GroovyScriptEngine to execute scripts that are in the script space. These scripts perform actions for the player, just like in an OS where the command "grep" or "exec" can be run by someone on the command line.

This is the command interpreter (stripped down). Its written in Java:



public class CommandInterpreter { 
    private GroovyScriptEngine groovyScriptEngine;

    ... 
public Object doCommand(final String command,
    String argsAsString, MudObject performingObject) throws ResourceException,   
    ScriptException {

  if (getGroovyScriptEngine() != null) {
   List argsAsList = null;

   if (argsAsString != null) {
    argsAsList = Arrays.asList
(argsAsString.split(" "));
   }

   Map bindingMap = new HashMap();
   
   bindingMap.put("argstr", argsAsString);
                        // ... etc 
   bindingMap.put("interpreter", this);
   Binding binding = new Binding(bindingMap);

   return getGroovyScriptEngine().run(command + ".groovy", binding);

  }

  return null;
 }

    
}

All you really need to know about this is that it runs a script that is defined in a directory somewhere. This script could be something like "look" or "say" or "jump" etc etc. and is passed a string of arguments (like say hello there)

However every time we want to run a command, we have to invoke "doCommand" which is a little clunky. What would be nice is if we could do something like this:


    MOBImpl ogre = new MOBImpl(name: "ogre")
    ... register it with the mud etc ...

    mob.say "I'm going to eat you!"

nice ... but we need it wrapped in a behaviour, because otherwise how would we know when to execute the commands? GroovyMud's triggeredBehaviour comes to the help. This behaviour is executed on the object whenever it receives an event from the MUD (ie, when someone leaves, enters, or whatever), and is called from the doEvent method, which is called by the mud whenever an event is received:


MOBImpl ogre = new MOBImpl(name: "ogre")
... register it with the mud etc ...

def triggered = new TriggeredBehaviour(eventClazz: ArrivalEvent)
triggered.triggerLogic = { event -> event.source instanceof Player }
triggered.behaviour = [doBehaviour: {mob, event -> 

      mob.say "I'm going to eat you!"
      mob.kill event.source

] as Behaviour
ogre.triggeredBehaviours << triggeredBehaviour

Ok so adding the new commands to the mob is easily done with groovy:


// stripped down Mud Object
class MOBImpl extends IObservable{
 def name
        def triggeredBehaviours
//.. other methods etc 

        def methodMissing(String name, args){
  def retObject = null;
  def argsAsString = args[0]

   if (argsAsString instanceof String) {
    retObject = interpreter.doCommand(name,
 argsAsString, this); 
   }else{
    throw new MissingMethodException(name, 
this, args)
   }
 
  
  return retObject;
 }
    void doEvent(IScopedEvent arg) {
  triggeredBehaviours?.each{it->
   it.doBehaviour(this, arg)
  }
    }
}

Using "methodMissing", we can pass the method on to the CommandInterpreter for processing. This way, when we add new scripts to the mud, any object can now perform any scripted action that the GroovyScriptEngine can find, and doEvent will call this behaviour when ever an event is received.

I have actually implemented this on the base MUD object, so that any object at all can perform commands!

Grooovy :D

MOPs not a problem

noreply@blogger.com (matt) — Tue, 19 May 2009 09:29:00 +0000

Turns out I was being an Id10t with the interface problem :(

I had missed out initialising the closure with the newly created bean in my examples.

Silly me :(

the fixed code is:


import b.*
def pogo = new GroovyA(name:"John", lastName:"Wombat") as Foo

pogo.fullName = {f, l, s -> "Hello $f $l, how much $s in your tea?"} // set the closure

def method = pogo.metaClass.getMetaMethod('getFullNameWithSugar', Object)

// Given the instance now, it works
println method.invoke(pogo, 'sugar')

// This was commented out in your JIRA code. This also works.
println pogo.fullNameWithSugar("f","sugar", "y")

standalone BeanBuilder broken in 1.1.1

noreply@blogger.com (matt) — Fri, 15 May 2009 21:09:00 +0000

Standalone BeanBuilder support is broken in GRAILS 1.1.1 :(

Best stay with 1.1 if you need BeanBuilder without GRAILS for a bit.

Alternatively (thanks to Graeme Rocher for the tip) you could add the grails core as a dependency.

Groovy 1.6.3 and Grails 1.1.1

noreply@blogger.com (matt) — Thu, 14 May 2009 22:05:00 +0000

Yay!

Groovy 1.6.3 is out, and so is Grails 1.1.1 :D

Goodbye bug 4537 (among others) :)

Stringy GStrings

noreply@blogger.com (matt) — Wed, 13 May 2009 11:55:00 +0000

Groovy introduces the concept of GStrings into your code. GStrings are cool, and very, very groovy.

However be warned that using GStrings and Java together (especially using interfaces) can be confusing.

Consider this:
//java


public interface StringyInterface{
    public String getFullName();
    public void setFullName(String name);
}

//groovy class

class MyClass implements StringyInterface{
    def name;
    def lastName;
    def fullName

    String getFullName(){
       return fullName
    }

    void setFullName(String fullName){
       this.fullName = fullName
    }

}

In a normal Groovy class, you would not define the getter or setter for lastName, Groovy would deal with it for you. But if you do not, then the compiler complains about it.

All goes wonderfully well until you try to assign a GString to lastName. The lastName variable is protected by the getters and setters defined by the interface so you cannot put ANY kind of GString (lazy or otherwise) into it without converting it to string first (toString()), which then evaluates the GString in the context of the calling code.

e.g.


def myBean = new MyClass()
myBean.name = "tom"
myBean.lastName = "thumb"
myBean.fullName = "${writer -> writer << \"$name $lastName\"}" 
// ^^^ complains about lastName and name

"But why dont you put the logic inside the getter to return the full name?" I hear you cry. Well, I could, but I should be able to do this kind of templating with a GString. Especially if I'm creating different kind of objects on the fly, that may have different rules for the position of name and lastname (for example) that are too simple or multifarious to bother putting in the class.

"But I could change the definition of the setter to take an Object parameter!!" I also hear you cry. Correct, you /could/ do this, but this would break Javabean conventions and if you are using a framework like Spring then Spring will complain about it :( A Javabean must have the same getter return type as the setter argument type or some such nonsense. This makes sense when you're in a strongly typed language like Java, but is very annoying when using Groovy.

However there is a way out!!!1! You can use the @ sign in front of the definition to directly access the lastName variable:


def myBean = new MyClass()

// yay this should work
myBean.@fullName = "${writer -> writer << \"$name $lastName\"}"

I feel better now. Phew.

GOTCHA:

If you are using a Grails beanbuilder, you cannot do this as it does not support it: no matter what, the beanbuilder tries to evaluate the GString in the context of the beanbuilder because of the interface setter!


   beanbuilder.beans {
      myClass(MyClass){
          fullName = "${writer -> writer << \"$name $lastName\"}" // boo, name not found
      }
   }
}

This is because there is currently no way for beanbuilder to do the @ magic above boo :(

Hopefully they will sort this out soon.

GroovyMud - the Java / Groovy Mud Engine

noreply@blogger.com (matt) — Wed, 13 May 2009 11:21:00 +0000

I'm quite a seasoned Java programmer now. Or I like to think I am anyways. So I wanted to put myself to the test a little, and begin a really ambitious open source project.

So I started writing a MUD code base.

Groovy!

Yes. It is. Written in Groovy (and Java). For the past year and a bit I have been consumed by my obsessive nature and produced something that kinda works OK.

It is still in heavy development, being redesigned to be more, er, Groovy - because Java *isn't* Groovy at all and I'm just not used to writing it.

I have had many, many issues. Mainly fighting with Java and Groovy to play nicely with each other. Java wants nicely typed interfaces. Groovy doesn't. Groovy being in heavy development too hasn't helped either: there are a number of bugs that I've had to raise just because I couldn't make Groovy do nice things.

Anyway, take a look at the source code. You can download version 2 off the googlecode website (http://code.google.com/p/groovymud), it doesn't support areas yet but the version in the trunk is fairly stable now, which does.

I will be writing some stuff about unit testing in Groovy on here in the next few months. And how to get things done with Java and Groovy (and Grails), which I think is missing a little from any of the documentation or tutorials you can find. I guess mainly because you either use Groovy, or you use Java.

Welcome

noreply@blogger.com (matt) — Wed, 13 May 2009 11:20:00 +0000

Hey

This is my blog. I'm going to put programming stuff on here so I can refer back to it in the future. I used to have a blog over at JRoller, but for the life of me I can't get back in to edit it.

So here I am.