Posts Tagged ‘Groovy’

Exporting from Vireo into DSpace

Wednesday, February 20th, 2013

The first version of the Vireo Electronic Thesis and Submission system was built as an addon to DSpace. It used the same technology stack, reused the underlying database and file storage, operated within the same UI. The original idea was that Vireo would deeptly integrate with the repository. Because of these decisions there was no separation between how Vireo stored it’s metadata and it’s Dublin Core encoding of the metadata. There was only one way, the Vireo way. If you wanted something else you couldn’t do it with DSpace. For example, if you wanted to store the author’s information in contributor.author you couldn’t. Vireo demanded that you use the creator field instead.

Vireo 2.0 broke this requirement bring more flexibility. The project is no longer deeply integrated with DSpace, or any other repository. Internally Vireo stores its metadata in relational tables in the format that is easiest for it to work with and does not conform to any particular metadata encoding. Then when data is ready to be deposited into the repository the SWORD protocol is used to deposit the content into the destination repository. During the SWORD deposit Vireo will generate a metadata package in a particular encoding format. These “export formats” are designed to be flexible so that different repositories can use different encodings. I’ve previously written a blog post on the technology behind these export formats if you are interested in customizing them.

(more…)

Customizng Vireo Export Formats

Sunday, October 21st, 2012

Vireo is a turnkey solution for Electronic Thesis & Dissertation (ETD) management from the initial point of a student’s submission, through the approval workflow, and to publication. This post gives an overview of how to export with data from Vireo into other systems.

The export system, introduced with Vireo 1.8, is a powerful and flexible mechanism for allowing other systems to use data from Vireo. The number of built-in formats supported by Vireo is greatly expanded, while also allowing for customizations at each institution. I hope that the new export system will prove to be easily customized by other developers without investing lots of time in learning the intricacies of the platform or java, and instead just focus or reformatting the data. If, you’re a developer working on customizing an export format please drop me a line and let me know how the experience went (or if you’re not finished I may be able to answer a question or two).

Maven vs Grails

Monday, May 31st, 2010

We have a Grails 1.1 which uses ant + Ivy as its build mechanism. The Ivy configuration has always been wonky, I wasn’t the person who set it up so I’m not exactly sure why it is that way. You would have to run this special ant target, “copy-jars”, which movies the libraries downloaded with Ivy around because some grails command would delete them.  When it came time to upgrade to the latest version, Grails 1.2.2, we wanted to address this problem. One of the new features touted for this release is its maven integration and since we use Maven for several of our other projects we figured this would be a good choice.

Our experiment upgrading to Grails 1.2.2 with Maven integration took a few days to work our way through the errors and gotchas.  In the end we were able to “successfully” upgrade our project – it compiled and passed all the tests. However it didn’t work that well. I’ve included my notes from the upgrade at the end of the post for anyone else who’s trying to do something similar. However in the end Grails + Maven integration sucked for a few reasons.

  • Tests will fail if you do not run a mvn clean in-between. So you can’t run mvn test, fix something then, re-run mvn test again and expect it to work.
  • Running the mvn package command required a larger amount of memory. I had to increase memory available via JAVA_TOOL_OPTIONS=-Xmx512m. This wasn’t required for our old Ivy-based build system nor is it required when using a pure grails build.
  • The build is fragile, minor changes would break in unexpected ways. But the worst part is any errors encountered were always hidden behind java invocation errors masking the real error. This makes debugging the build much harder.
  • In general the integration is very immature, maybe in the future this will improve. But at this state if I can’t recommend this to anyone.

In the end we decided that Maven integration just wasn’t worth it, and we needed something better. The next option we looked at was a pure grails-based build system. This option worked well, there we’re no errors or gotchas like the previous experiment. The best part is that it is able to pull dependencies from Maven without dealing with maven! It’s pretty simple, as described in the manual, just set your dependencies into grails-app/conf/BuildConfig.groovy. That’s it, you’re done. Run “grails compile” and you’re dependencies will be downloaded and the application compiled. This just took a an hour to figure it all out and show it working compared to the days it took getting the Maven integration barely working. In the end I highly recommend using a pure-grails based build, it is a 1000 times better than the traditional Maven integration.
(more…)