I recently constructed a new, local/development instance of ISLE (see my previous post) largely in order to debug a mystery in Digital.Grinnell’s display of oral histories. My Trello card for the issue reads:
Our newest AOH entries, and some older objects, will not display a transcript after upgrade to the latest version of the OH module. OHScribe is needed to aid in re-processing transcripts for these objects, and some XDebug work will also be required.
In case you’re not already familiar with these projects, they both represent “starting points”, largely config and .xslt code that’s intended to be customized. In my experience this adds up to trouble since maintenance and upgrade of any multi-faceted, customized code like this can be tedious and therefore, dangerous.
The crux of my problem is that these repos use very long Java/Tomcat paths, and the most significant of these is /usr/local/fedora/tomcat/webapps/fedoragsearch/WEB-INF/classes/fgsconfigFinal/index/FgsIndex/. However, in a standard ISLE instace the equivalent path must be /usr/local/tomcat/webapps/fedoragsearch/WEB-INF/classes/fgsconfigFinal/index/FgsIndex/. See the difference? The ISLE path does NOT include a ../fedora/.. subdirectory like the Discovery Garden paths do.
Unfortunately, when I updated my FGSearch and Solr configs earlier this year I missed some, but not all, of these ../fedora/.. directory references during a “manual” compare and merge process, and that made things like oral histories go afoul, and without much warning.
My solution to this problem going forward is the creation of this new public repository. The repo’s description in GitHub describes is:
The contents of isle-fedora-ld’s /usr/local/tomcat/webapps/fedoragsearch/WEB-INF/classes/fgsconfigFinal/index/FgsIndex directory
The repo has no README.md file, yet, because the description is so succinct and accurate; but I’ll make it a point to add more detail soon.