One response to my Dear User of My Open Source Project post went as follows:
You know what would be great? If you put out a list of things that you would want us to help you with.
So here goes.
A huge recurring issue with Autobase is the LbdslProperties not being compiled when create-migration is run. This happened when people complained about lbdsl.jar being a distinct project, and therefore Autobase being harder to maintain (which is true). Now, unfortunately, if the project isn’t compiled (for instance, if it’s just after a clean), the create-migration script won’t be able to find LbdslProperties. I think removing the LbdslProperties import and replacing it with something like this will work:
includeTargets << grailsScript("Compile") compile() def LbdslProperties = Class.forName("liquibase.dsl.properties.LbdslProperties", true, this.class.classLoader) assert LbdslProperties
An alternative and more general solution would be to create an Autobase-src project that provides most of the work for Autobase, and package it up in a JAR (move consolidation in the opposite direction).
A branch of Autobase needs to queue up using Liquibase 2.0. MAJOR improvements in functionality and a few bug fixes there. Most importantly, the Liquibase-DSL part of Autobase should take advantage of the extensions API. That would probably even qualify for a prize via the LiquiBase Extension Content 2009, assuming you get it in fast enough.
There’s also a few JIRA tickets to check out. And JIRA to be maintained in general.
The original vision of Autobase had people writing migrations very rarely: instead, people would do things like:
grails migrate-domain rename Foo.bar Foo.baz
This would rename the bar field of the Foo class to be baz (provided bar exists and baz doesn’t), and create the appropriate migration with all the paranoid safety checks in place. That kind of full-featured approach is why Autobase is called Autobase. Even just creating a set of standard migrations would be huge.
The JConch library could use some love. In particular, the CacheMap implementation needs to change: it should just wrap a properly-configured output of Google Collection’s MapMaker. Their ForwardingMap should make that pretty easy.
JConch was also intended to have some type-safe pipelining and a concurrent process builder with a non-crappy API. That work got abandoned when I left the project where I was going to use it, but I’d still like to see it and have some ideas. It’s a perfect opportunity for some polyglot programming.
Typesafe monadic processors in JConch would be even more awesome.
Also, JConch needs to have Ivy support: it should specify its dependencies and be able to be retrieved via Ivy. I have space to host the repo if someone else can figure out how to work it.
GORM Labs could use a Foo.random (for retrieving a random element), Foo.randomByXXX (random element in the dynamic finders), and foo.barId (for retrieving foo.bar.id: if bar is initialized, just fall back to foo.bar.id; if bar isn’t initialized, do a query to the DB for foo.bar.id and cache the result).
Other GORM Labs goodies can be found under “On the Docket” on the GORM Labs page in the Grails plugin portal.
@WithLog (more info here) should also be able to be triggered via an interface. Think compile-time mix-in (Look, ma! I can be polymorphic over this, too!).
@WithLog should not trounce existing static log properties.
Some benchmarking work should be done to see if having @WithLog create both static and instance properties would be beneficial (might reduce effort involved in property look-up; also creates overhead on object creation).
Sublog should be modified to automatically apply @WithLog to those classes whose binary name match a regex (or some element of a list of regexes). And certainly have it automatically apply to everything in ./grails-app.
The jQuery PeriodicalUpdater should be updated to use jQuery.ajax‘s dataFilter to track if changes have occurred in the response (string-identical responses should be treated the same way as 304 responses).
A demo page/app for the jQuery PeriodicalUpdater would be nice, too. Sounds like a nifty little way for someone interested in learning Groovy servlets and GAE. Or just query Twitter’s public timeline or something.
G-Func (which is Marc Palmer‘s project, but I love and contribute to it) needs some work to better support AJAX and multiple clients. Marc’s got details.
I’ve noodled around with but have not managed to get a working implementation of SSA built on top of bytescript.
Related posts:
Pingback: Updated GORM Labs and JQuery PeriodicalUpdater | Enfranchised Mind