2013 marc breakout

Attendees: some with no MARC4J/SolrMarc experience, some using MARC4J outside of SolrMarc.

Basics

What is it? Java library for working with MARC records.

Supports MARC21 and Unicode; may be more robust for MARC21.

Migration

There is now a Marc4j organization on GitHub to migrate content out of Tigris/CVS.

Goal: centralize management of the project so versions can be tracked more easily (i.e. no more custom versions bundled in SolrMarc that exist nowhere else).

No objections to moving Marc4j to GitHub.

Bob will talk to Bas about putting a "we've moved" notice in the old Tigris/CVS repo.

Other Issues

ICU4j embedding

Issue: Marc4j builds its code tables using a normalizer borrowed from the ICU4j library. ICU library is huge, so normalizer is bundled into Marc4j by itself. This saves space but makes it more complex/difficult to update ICU4j dependency.

Should we continue to bundle subset of ICU4j, or should we simply add ICU4j as a straight dependency and not worry about the space savings?

Group decision: yes. No objections.

Version Numbers

Current GitHub version is 2.5.1 beta.

Proposal: clean up/test, then start semantic versioning with 2.6.0.

Start release notes/change history file in repo. Joe will look into this.

Group decision: yes. No objections.

Test Coverage

Current level of coverage: unknown.

Possible project: borrow tests from other MARC libraries and adapt for Marc4j to improve coverage.

Continuous Integration

Simple solution: create Travis-CI hook in GitHub to run tests (probably using existing Ant script for now).

Future project: begin measuring test coverage.

Dependency Management

We need to get Marc4j into the Maven central repository so that it can be easily included in other projects.

Bill Dueber will look at introducing Ivy for dependency management within Marc4j.

Simon's Pull Request

Simon Spero submitted a large pull request to rearrange code (including some Ivy-related work). Bob will review.

Integration with Eclipse

Bob could use some help with checking code out of Git and getting it working in Eclipse.

Moving code to Marc4j

SolrMarc contains some custom MARC readers that are generic and reusable enough to better fit in the base Marc4j library. There were no objections to moving these up to Marc4j for greater availability.

Expanded Use of Mix-Ins

Bob has developed "mix-in" mechanism for writing custom routines in a stand-alone way. He would like to see more use of these in place of the custom system-specific examples. This simplifies the project structure and allows easier sharing of routines that may be useful to various members of the community.

Documentation is in progress, plus development of "SolrMarc mix-in development kit."

Some discussion of where mix-ins should live: as part of SolrMarc repo, or elsewhere? Would dependency management with Ivy (for example) help with this?

Demian volunteered to help refactor the GenericVuFind example to mix-ins as a first step in evaluating how to proceed; Tod is doing some mix-in work already and will help advise this process.

Naomi pointed out that we can trash the GenericBlacklight and Stanford examples as they are out of date and no longer in use.

Number of .jars

Naomi asked about the current situation of bundling most of SolrMarc into a single .jar; Bob stated that this adds some benefits and some restrictions/complexity. The one jar approach is a good way of avoiding "class not found" errors but it makes the build process more complex.

After Bill investigated Ivy for Marc4j, perhaps his new knowledge can be applied to investigating an alternative to the current complex Ant scripts.