After reading a post on one of my favorite blogs, Giant Robots Smashing Into Other Giant Robots, I was inspired to start this series chronicling highlights in our Open Source development efforts.
It was a busy week for the Scholars’ Lab R&D team, with updates to the FedoraConnector, NeatlineMaps, and Timeline plugins for Omeka, as well as updates to our Vagrant cookbooks (and an Omeka dev example), and BagItPHP library.
David McClure (davidmcclure) greatly improved the workflow for updating metadata from FedoraCommons objects in to an Omeka instance 04b8ee8. Users can now set not only system-wide defaults for polling updates to metadata records from a Fedora server, but also on a per-field basis within individual records, giving users greater control over their metadata pulls.
David McClure (davidmcclure) also has begun work on a major refactor of the NeatlineMaps plugin on the refactor branch of the project. There is now much smarter support for dynamically determining a map’s bounding box (c4090fe). Just a note if you are checking out this branch: this commit (032adf3) adds the map in the item view, but is default code and displays the map incorrectly due to a bug in the projection. Next up is a major revamp of the administration interface, which will provide a facade for GeoServer inside of Omeka, making it easy to manage collections of maps and assign them to servers and namespaces.
Jeremy Boggs (clioweb) has re-implemented the Timeline plugin to use the jQuery Timeglider plugin. This update (b078df8) replaces the plugin’s use of the SIMILE Timeline and begins to add support for a custom JSON output (51eb12a) for Omeka records for use in Timeglider timelines.
Eric Rochester (erochest) has been working on standardizing our development, testing, and deployment environments using virtual servers with Vagrant. He has set up a repository of cookbooks which automate the setup of development environments for various projects. For a cool example, check out the dev environment for our project with Louis Nelson, chronicling the architectural development of Falmouth Jamaica.
We spent some time this week moving our Omeka plugins (and other libraries) to a new Jenkins server. In getting the PEAR/Pecl packages properly set up, Wayne Graham (waynegraham) updated the ant script for the various testing and code reports that we run on our software (465fa89).
To better automate our testing environment, David McClure (davidmcclure) worked out the final issues with automating the testing of our plugins with multiple versions of Omeka. We are currently targeting the current stable tag of Omeka, and the master branch. We are working on turning everything green, but the major work of integrating the plugins in to the test environment is complete. It took a bit of tinkering to get the plugins to build correctly when they’re not sitting inside of an Omeka installation tree (as they would in a standard configuration). Watch this space for a more detailed post about how to replicate this set up.