Andrew  (and other VuFind folks)

SolrMarc is a day or two from a new release.   The SolrMarc code itself has been made to be completely agnostic with respect to the version of solr that is in use (it has been tested with 1.2  1.3   and a pre-release verion of 1.4). 

During the build process you can specify which version of solr you want to use,  and the build will include the necessary jars from one of the three different solr lib directories.   Or you can even specify the location of the solr.war file that you are using and the build process will unbundle the necessary jars from that war file, and include them in the SolrMarc.jar file that is produced. 

Currently this latest code is in the solrmarc-2.0 branch in the SVN repository, but it will be moved to the trunk in the very near future.

The solrmarc-2.0 branch currently includes a couple of example setups,  one for the generic Blacklight demo,  one for UVA's implementation of Blacklight, and one corresponding to stanford's implementation.   It would probably be a good idea to include a example setup for VuFind as well.

    -Bob Haschart

Andrew Nagy wrote:
Yeah - that's a good point.  Right now SolrMarc and VuFind are 2 separate projects and will remain so.  My first guess is that SolrMarc should not be reliant on the solr jars so that you can use SolrMarc with whichever version you happen to run.  Maybe this should be a runtime param with SolrMarc.

I don't think maven will help solve this problem since solr can change drastically from one day to the next and they only release "numbered" versions every 6 months to a year at least.

I cc'd the solrmarc list - maybe Robert can chime in here.  It's been a while since I have participated in the SolrMarc community - so I need to reaquaint myself with the code.


On Wed, Feb 18, 2009 at 3:03 PM, Barnett, Jeffrey <> wrote:

I notice you making the point that *both* vufind and solrmarc now come with associated solr.jar files.  Is this a temporary or permanent situation? How will we be able to assure that the versions packaged separately will be compatible at run time?  Are we approaching a Maven Moment?


From: Andrew Nagy []
Sent: Wednesday, February 18, 2009 2:48 PM
To: Barnett, Jeffrey
Cc: Lovins, Daniel;
Subject: Re: [VuFind-Tech] Blanks appearing in Language facet


It's probably best to copy over the solr jars if you are running an updated solr into the solrmarc project just to make sure there are no chances for failures.

I will add this to my list to grab the latest solr for both vufind and solrmarc.


On Wed, Feb 18, 2009 at 2:44 PM, Barnett, Jeffrey <> wrote:

Bill Dueber just posted a recommendation on grabbing the latest Solr build to capture a fix for the spellcheck module.  Will the newest SolrMarc include this fix as well?  Any dependencies in other parts of Vufind?


From: Lovins, Daniel
Sent: Wednesday, February 18, 2009 2:30 PM
To: Andrew Nagy

Cc:; Barnett, Jeffrey; Sun, Dajin; Riley, Charles

Subject: RE: [VuFind-General] Blanks appearing in Language facet



Thanks for the super-quick response.


I'll check with Jeff about the latest solrmarc and changing the properties file.




From: Andrew Nagy []
Sent: Wednesday, February 18, 2009 2:25 PM
To: Lovins, Daniel
Cc:; Barnett, Jeffrey; Sun, Dajin; Riley, Charles
Subject: Re: [VuFind-General] Blanks appearing in Language facet


Daniel - its funny that you brought this up.  Last week I just committed a fix for this to the SolrMarc code base.  I noticed that our language logic needed to be more detailed, so I built a custom function in SolrMarc to parse the languages correctly.

If you are up to it - grab the latest solrmarc and try it out to see if this fixes your problem.

You will need to change your file to use the following line:

language = custom, getLanguage,


On Wed, Feb 18, 2009 at 2:20 PM, Lovins, Daniel <> wrote:

Hi all.


We discovered something here that I was planning to report on JIRA as a bug, but thought I'd bring it up first on the list.


If we search the following book in our database: "Hoffmanns Erzählungen", we notice a blank line in the language facet indicating 3 hits. There's no way to click open the facet directly since there's nothing there to click on, but my colleague Chuck Riley was able to determine that, because they were cataloged according to an earlier version of the MARC 21 standard, records like this have multiple 041 subfield $a language codes that are not separated by subfield delimiters. So, for example, an item that includes English, German, French, and Spanish language would have "041 $a enggerfrespa" for an. The latest version of MARC 21 specifies repeatable subfield $a delimiters (e.g., "041 $eng $a ger $a fre $a spa"), but this is a fairly recent change, which means there are many legacy records. When the delimiters are present, VuFind parses and displays the languages correctly. When not, VuFind seems to represent the undefined string of characters as blanks.


We're thinking about trying to add the subfield delimiters retroactively, but we're also wondering if others have noticed this issue, and, if so, whether anyone's found a way to represent the concatenated language codes as something other than a blank facet.


Thanks for your help.







Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
VuFind-General mailing list



You received this message because you are subscribed to the Google Groups "solrmarc-tech" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at