more sakai woes

Fri, Sep 21, 2007

Seems every post I write about Sakai is one of doom and gloom! That’s mainly because I work with trunk. In fact that’s all I work with, so it’s bound to be a bumpy ride. This time in the diary of a Sakai developer, I must note that my local install of Sakai trunk finally gave up the ghost.

A rogue Hibernate library had infiltrated shared/lib and stopped all the content hosting components from loading. I have absolutely no idea how it got there. Maven again. I deleted it, as the correct one should be Then I restarted Sakai and it instantly went haywire with terminal class problems. Time for a reinstall.

Quite how it got so messed up is a mystery but that’s prolly Maven for you. Anyway, I binned tomcat, got a clean one, did an svn up and now the chaos gone off the scale:

org.sakaiproject.util.BaseDbSingleStorage is not abstract and does not override abstract method getAllResourcesWhere(java.lang.String,java.lang.String,java.lang.String,int,int) in org.sakaiproject.util.DbSingleStorage

That’s a pretty terminal error. Not sure why such code is actually in trunk. Source repositories shouldn’t be used as code backups. It should compile before it’s committed. Whatever. That’s the end of CTREP development for now until a working trunk reappears. I’m in the process of plumbing the Fedora skeletons into Sakai content hosting but this has stopped me for now. Hopefully someone will fix the problem, soon.

comments powered by Disqus