Developer Track: DSpace 4 and Hyku (Upgrades and Customizations)

2 presentations: Why harvest your own DSpace? Benefits of separating repository and searchAri Häyrinen, Veli-Matti Häkkinen, Miika Nurminen, Toni TourunenUniversity of Jyväskylä, FinlandJYX is the institutional repository of University of Jyväskylä (JYU). The repository has been in use since 2008 containing over 90000 items of various types including publications, theses, datasets, historical maps, and audiovisual material. JYX utilizes DSpace software with customizations and REST-based integrations such as retrieving self-archived materials from CRIS and other publication workflows using external tools. In addition, JYX provides metadata via OAI-PMH for other services such OpenAIRE and Finna2, the national search service for archives, libraries, and museums. Because of DSpace-related customizations, upgrades have turned out to be complex efforts, especially preserving UI-based customizations such as special formatting for restricted items. When the support for DSpace 6 ended in 2023, we faced a choice: to work within the native DSpace UI or to build something more flexible. We chose to decouple repository and user interface. This presentation explores the technical and functional benefits of using an external search engine (VuFind) to "harvest ourselves. "Unpacking Hyku Knapsack: Sustainable Customization With Less Upgrade PainShana Moore, Notch8, United States of AmericaRepository programs always need local customization (metadata defaults, workflows, branding, integrations). The trouble starts when those changes land in core code: upgrades become archaeology, diffs sprawl, and “we’ll upgrade later” turns into years. Hyku Knapsack is how we avoid that in the Samvera Hyku ecosystem. It’s a wrapper repository that keeps upstream Hyku as a Git submodule and keeps institution-specific code in the wrapper. Rails loads the wrapper first, so local overrides win without forking upstream. In this Developer Track session I’ll do a quick architecture overview, then a live demo: adding a custom override the knapsack way (mirror upstream paths, use decorator. rb, prefer super, and use Module#prepend when needed). I’ll close with upgrade/migration tips and a simple rubric for what should live in your wrapper versus what belongs upstream.