Difference between revisions of "2013 marc breakout"
Demiankatz (Talk | contribs) |
Demiankatz (Talk | contribs) |
||
Line 61: | Line 61: | ||
Simon Spero submitted a large pull request to rearrange code (including some Ivy-related work). Bob will review. | 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. | ||
+ | |||
+ | == SolrMarc == | ||
+ | |||
+ | === 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. |
Latest revision as of 21:57, 12 February 2013
Attendees: some with no MARC4J/SolrMarc experience, some using MARC4J outside of SolrMarc.
Contents
Marc4j
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.
SolrMarc
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.