sakai trundling along again
Fri, Sep 21, 2007
Spoke too soon. Or perhaps not. Seems I caught trunk with its knickers down, again. I waited a while then did an svn up on db and it built. Trying to start the damn thing was another mess though. A sudden requirement for a UTF-8 database has appeared, something to do with binary guff, so I blew away the old database and created a new one, UTF-8 enabled. That cured that problem and the rickety cart nudged forward a few feet, ‘til the next problem.
Seems the GSK has Jakarta Oro and classpath problems. The AOP proxy lives in components but it’s called from SpringCompMgr as it’s a BeanPostProcessor. Oro is on the processor’s CLASSPATH but not SpringComMgr CLASSPATH, as that comes out of shared/lib. The quick solution was to bung oro in shared/lib, just to get Sakai started and get on with CTREP. I’ll need to take a closed look at that CLASSPATH problem later though. I’m not sure how this has come about as I tested the AOP before committing it to Tetra contrib. Then again, a lot of strange things happen with Sakai trunk, such as the rogue Hibernate jar appearing from nowhere and causing this mess in the first place.
The outcome of this trunk trauma however, is the Fedora skeletons are now plumbed into Sakai’s content hosting framework. All that needs done now, is implement them.
I’m sure when it’s all working and people are using it, I’ll be able to stand back and appreciate the maze of class loaders and dependencies that Sakai must endure. Perhaps.