Archive for the ‘Autobase’ Category
New Version of Autobase: Payware? October 27, 2009 | 12:13 pm

Since nobody’s come out of the woodwork to fund the Autobase Grails plugin, but that plugin desperately needs a new version and extensions, so I’m considering working on it over the holidays and releasing it early next year as payware, or perhaps under a GPL/payware scheme a la Zed Shaw’s GPL approach or Clojure’s use of the SCA. Note that using a plugin under the GPL will GPL your code by extension.

I don’t want Autobase to stagnate and die, but I also can’t afford to be burning time on something that won’t produce money in some form: grad school is sucking up all that kind of time.


Grails Retainer October 6, 2009 | 07:11 pm

In the past, I have been picked up on some projects for my specialty with Groovy DSLs, GORM, and Grails infrastructure. I am a specialist in those areas, and my rate reflects that. The problem came in if there wasn’t enough DSL/GORM/infrastructure work to be doing: I would then be shifted to other development tasks, and although I am capable in these other areas, it’s not where I bring the most value.

The retainer model establishes a monthly flat rate where I just do the work within my specialty, where I bring the most value for my billable hour. My billable hours under the retainer system could be used for tackling development tasks directly, but a better use is to have them be pair programming or Q&A/training sessions, so that I can communicate the skills I have directly to your project.

In addition, bringing me on as retainer for your project brings in active e-mail support and can be a great way to drive the development of GORM Labs, Autobase, and Robert’s other open source projects.

For more information and rates, see Grails Retainer on

Open Source Journaling: Autobase v0.8.1 February 9, 2009 | 12:12 am

Did a bunch of work on Autobase tonight, culminating in a v0.8.1 release.

  • First, I upgraded to Grails 1.1b3. This wasn’t that big a deal, except they moved the staging directory on me, so I had to shift to using stagingDir on the eventWarStart to populate the war. That was on the to-do list for Autobase anyway, so it’s good it got done.
  • I also added a bit of a short-cut for things that have raw bodies (like the “sql” change) — bare string arguments will be set to the “sql” property. This isn’t the best solution for that, but the best solution involves upstream changes in Liquibase — it needs to somehow signal that a body is expected and what property to set with that body. Or (less OO-y), simply a helper object that takes the change and the string and applies it appropriately. This is probably coming in Liquibase 1.10, so the “sql” stopgap is only temporary.
  • I fought again with the whole column/where problem. The methodMissing dispatching was introducing arrays (instead of ArrayLists), missing existing methods, and other weirdness. I punted over to groovy.util.Proxy, but discovered that a proxy of a proxy fails. So I had to leave the dirty hack in place, because I just can’t get the meta-object magic to work.

Autobase Released October 29, 2008 | 12:13 pm

I’m officially releasing the Autobase plugin for Grails. It’s technically a 0.2 release — if I get a lot of positive feedback and implement a couple more features (see JIRA for Autobase), then I’ll do the official 1.0 release.

From “The Impetus“:

The Grails framework is the best web development framework out there right now. One of the things that makes it so impressive is that it has a unique paradigm: leverage existing, proven open-source technologies, but ship them with a set of reasonable defaults and preconfigure them to work well with eachother. The result is something that provides exceedingly fast development while still having a mature core.

Before the Autobase plugin, there simply wasn’t a way to manage databases which fit in that same paradigm. The Liquibase plugin provided a raw way of bolting the excellent Liquibase system onto the side of Grails, but there was a lot of XML and some weird commands and it didn’t really flow with the otherwise smooth Grails development process. The dbmigrate plugin mirrored Rails’s problematic initial swing at database migrations and left you having to hand-code up SQL. And it still didn’t flow with the Grails development process—if I forget to run “grails migrate” after pulling code from git, I’d be in trouble. And if I wanted to deploy my application as a war instead of as a set of files, I’m in real trouble.

This just wouldn’t do. So, being an open source, DIY kinda guy, I set to writing up an alternative. Something which made it easy to handle migrations. Something which supported deployment as a war or as flat files. Something which leveraged a proven open source technology. Something which, in short, followed the Grails paradigm and kicked ass. Autobase is the result.

~~ Robert Fischer, Smokejumper Consulting