Blacklight

Release 3.2.0 of Project Blacklight is now available via Ruby Gems. We've posted an upgrade guide to the Blacklight wiki Blacklight 3.2 Release Notes and Upgrade Guide, with information about upgrading to use the asset pipeline, new per-controller configuration, and more. Here are the major new features in Blacklight 3.2:

• This release requires Rails 3.1 and the Rails asset pipeline.
• CSS uses the asset pipeline (as SCSS) and support modular overriding of styles
• Catalog configuration was refactored from a global configuration to a per-controller, DSL-based configuration
• Facets rendering refactor, which makes it easier to override the display of facet fields
• Updated blacklight-jetty to use Solr 3.5 (and update the version of SolrMarc distributed in Blacklight to 2.3.1)

The JIRA issues are at Blacklight 3.2 release

The full source code can be found on GitHub

Also, the GitHub compare view of this release vs. our last release is located at v3.1.0...v.3.2.0

Release 3.1.0 of Project Blacklight is now available via Ruby Gems. Instructions for installing Blacklight or upgrading an existing installation can be found on our wiki. Here are just a few things that are new in Blacklight 3.0:

• Fixes for various deprecation warnings and other features for Rails 3.1 compatibility (note that Rails 3.1 asset pipeline/scss work will be in a future release, this is purely compatibility work)
• Patches from the Hydra Project cleaning up our code (thanks Justin!)
• Fix for CODEBASE-350: kaminari performance terrible with large number of pages. If you've made local modifications to your pagination template, be sure to read through the ticket.
• Removed integrated unAPI support. The mechanism unAPI was changed into a (loosely) controlled vocabulary in HTML5 and the unAPI maintainers were uninterested in the HTML5 "link relation" process. unAPI support is still available through the blacklight_unapi plugin (https://github.com/cbeer/blacklight_unapi) if you wish to continue using unAPI.

The JIRA issues are at Blacklight 3.1 release

The full source code can be found on GitHub

Also, the GitHub compare view of this release vs. our last release is located at v3.0.0...v.3.1.0

Release 3.0 of Project Blacklight is now available via Ruby Gems. Instructions for installing Blacklight or upgrading an existing installation can be found on our wiki. Here are just a few things that are new in Blacklight 3.0:

• Installable as a Gem
• Rails 3.0 and 3.1 compatible
• JRuby Support
• Ruby 1.9.2 Support
• Automated Installation via Generators (rails generate Blacklight)
• Reduced dependencies (no longer requires Authlogic)
• Uses the new Rails3 engines for easier integration into your existing application

The JIRA issues are at Blacklight 3.0 release

The full source code can be found on GitHub

Also, the GitHub compare view of this release vs. our last release is located at v2.9.0...v.3.0.0

This is a relatively minor release, however it will be the last release that supports Rails 2. Shortly after this release, the "master" branch of Blacklight will be Rails 3 only. Future releases will distributed as Rails 3-compatible gems. Details on this migration, and documentation to assist implementors during the migration process will be forthcoming.

For Blacklight 2.9.0, the major feature is the solr_search_params refactor (CODEBASE-307 and documented on the wiki). For implementations that heavily customized the search experience, be sure to read the documentation around this new feature and update your applications accordingly.

There are also a handful of bug fixes, mainly in the test suite.

The JIRA issues are at Blacklight 2.9 release

Also, the GitHub compare view of this release vs. our last release is located at v2.8.0...v.2.9.0

List of fixes and enhancements for this version can be found here.

Highlights include:

• upgrade to work with Rails 2.3.11
• improved add/remove bookmarks and selected items UI
• improved JS behavior architecture, more easily over-rideable and re-useable in your local app
• built-in unAPI support
• changed email/SMS architecture for easier per-format-type local over-riding

Also, the GitHub compare view of this release vs. our last release is located athttp://github.com/projectblacklight/blacklight/compare/v2.7.0...v2.8.0

NOTE WELL: After upgrading from a former version, you will need to add these two lines to config/blacklight_config.rb (or any other initializer) in order to maintain email/SMS functionality:

    # Email uses the semantic fields mappings below to generate the body
    # of an email.
    SolrDocument.use_extension( Blacklight::Solr::Document::Email )

    # SMS uses the semantic fiels mappings below to generate the body of
    # an SMS email.
    SolrDocument.use_extension( Blacklight::Solr::Document::Sms )
    

Blacklight version 2.7 is now available on GitHub. You can find the 2.7.0 tagged release at http://github.com/projectblacklight/blacklight/tree/v2.7.0.

BL 2.7 introduces the ability to “cherry-pick” records from both the search results and record view into a folder to be bulk exported later. In addition to cherry-picking this release fix a few minor bugs.

To see major features or fixes included in 2.7 see:

http://jira.projectblacklight.org/jira/browse/CODEBASE/fixforversion/10054

To see a list of every single code change, via git commits, between 2.6 and 2.7, see:

http://github.com/projectblacklight/blacklight/compare/v2.6.0…v2.7.0

Blacklight version 2.6 is now available on GitHub. You can find the 2.6.0 tagged release at http://github.com/projectblacklight/blacklight/tree/v2.6.0.

Users are encouraged to use BL 2.6, it has a bunch of changes from 2.5,
including refactorings to allow local over-riding and configuration, as
well as add-on plug-ins, to integrate more cleanly. 2.6 is neccesary
for the existing add-on plugins like advanced search and date range
limit. 2.6 also includes major improvements to Atom and RSS feeds.

To see major features or fixes included in 2.6 see:

http://jira.projectblacklight.org/jira/browse/CODEBASE/fixforversion/10040

To see a list of every single code change, via git commits, between 2.5
and 2.6, see:

http://github.com/projectblacklight/blacklight/compare/v2.5.0…v2.6.0

Blacklight version 2.5 is now available on GitHub. You can find the 2.5.0 tagged release at http://github.com/projectblacklight/blacklight/tree/v2.5.0.

We have taken steps to improve the installation process with a new an improved installer. Instructions for installation are at http://github.com/projectblacklight/blacklight/blob/v2.5.0/README.rdoc. The process for installing the plugin, downloading/installing Solr, and downloading/indexing the test/sample data is all much more streamlined.

Here are the other notable changes for Blacklight 2.5.

Release Notes – Blacklight Plugin – Version 2.5

Bugs

• [CODEBASE-180] – Tabbing around in Blacklight does not show link outlines
• [CODEBASE-196] – Index action of CatalogController using Mash not SolrDocument
• [CODEBASE-204] – Command+Click not opening record links in new tab.
• [CODEBASE-213] – search_field parameter not preserved on sort/per_page change.
• [CODEBASE-223] – RefWorks export of non-ascii diacritics problem.
• [CODEBASE-225] – Sort and per page forms are generating action and controller hidden fields.

New Features/Improvements

• [CODEBASE-98] – Get shareable EAD/MODS data.
• [CODEBASE-136] – Librarian MARC view.
• [CODEBASE-175] – Add cucumber features for show view of the CatalogController.
• [CODEBASE-179] – Blacklight version needs to be clearly identified.
• [CODEBASE-189] – Advanced Search plugin (separate install).
• [CODEBASE-200] – Upgrade version of SolrMarc that we ship with Blacklight to 2.1.
• [CODEBASE-201] – Better handling of Solr errors (More appropriate stack traces/status codes depending on environment).
• [CODEBASE-205] – Rake task for indexing test data to more flexibly execute from the app level and plugin level.
• [CODEBASE-207] – Add new Blacklight logo to plugin’s theme
• [CODEBASE-208] – SolrDocument extensions.
• [CODEBASE-222] – Upgrade to jQuery 1.4.2 | Add jQuery UI 1.8.1.
• [CODEBASE-209] – Make all old jQuery lightboxes use jQuery UI dialogs.
• [CODEBASE-214] – Add :show_in_simple_search option to search_field logic.
• [CODEBASE-215] – Change how we’re supplying facet limits to Solr.
• [CODEBASE-216] – Allow code to add JS, CSS, and other HTML head content, in a loosely coupled way.
• [CODEBASE-218] – Application level ApplicationController needs to require_dependency not require the plugin’s ApplicationController.

Release 2.4 of Project Blacklight is now available in our new Git flavor! You can find the new improved flavor of Blacklight at http://github.com/projectblacklight/blacklight/tree/v2.4.0

In addition to our move to Git, we have listened to community feedback and have changed the installation process. Instructions for installation are at http://github.com/projectblacklight/blacklight/blob/v2.4.0/README.rdoc. In broad terms, Blacklight now uses a template to get required gems at installation time rather than bundling them in with the code.

Besides our debut in Git and the move to a template, here are the changes for release 2.4:

Release Notes – Blacklight Plugin – Version 2.4

Bug

• [CODEBASE-54] – rake gems:install does not work (using template now)
• [CODEBASE-111] – Ae and Oe ligature characters are not normalized correctly
• [CODEBASE-131] – Getting error from rails on startup that VERSION is already defined
• [CODEBASE-134] – Authlogic error
• [CODEBASE-135] – Fall back on net_http when curb gem is not present when using RSolr
• [CODEBASE-138] – A copy of ApplicationController has been removed from the module tree but is still active
• [CODEBASE-160] – why isn’t the email and SMS working on demo.projectblacklight.org
• [CODEBASE-170] – Blacklight logo cannot be over-ridden
• [CODEBASE-178] – 3 specs fail when run with rake solr:spec … no idea why
• [CODEBASE-187] – bookmarking seems to be broken in the latest code

Improvement

• [CODEBASE-87] – Gracefully handle solr errors
• [CODEBASE-172] – demo – solr config – only build spell dictionaries on optimize, not on newSearcher / firstSearcher

New Feature

• [CODEBASE-3] – exporting to Zotero
• [CODEBASE-109] – sort by pub date in demo
• [CODEBASE-182] – Rails “Template” installer instead of ./script/plugin
• [CODEBASE-183] – Add cursor focus to the search box on the home page
• [CODEBASE-190] – Cursor focus in search form on home page

Task

• [CODEBASE-51] – Design a basic advanced search UI – see Stanford SearchWorks
• [CODEBASE-70] – Need a plugin release as well
• [CODEBASE-114] – demo index should have vernacular displayed
• [CODEBASE-146] – Change stylesheet link in the HTML to media=”all”
• [CODEBASE-151] – get some dublin core test data
• [CODEBASE-159] – get test data with call numbers
• [CODEBASE-173] – marc_mapper.rb – no longer in synch with solrmarc; its presence is confusing.
• [CODEBASE-176] – get continuous integration working again
• [CODEBASE-177] – update demo app and readme at projectblacklight.org
• [CODEBASE-186] – Implement Google Analytics on the main blacklightopac.org site

Dear Blacklight Community,

The committers on the project have been discussing for some time now a move to git from subversion for source code management. The time has come to make that switch. Moving to git will allow us to more easily branch and merge changes, which will make it easier to have a greater number of people working on the code base at once without stepping on each other’s toes. It will also make it easier for folks who aren’t official committers to the project to make code contributions, and for us to accept them and merge them into the core code base.

The new source code repository will be available at http://github.com/projectblacklight

We will make the switch on Wednesday the 9th 23rd of September. Before that time we hope to have re-written the documentation for checking out source code, re-configured our hudson continuous build system to use git instead of svn, and re-written our capistrano deploy scripts that come with the demo app, but some of this may lag behind the actual switch. Please bear with us as we make the change, and help us out by reporting any places where we’ve missed documentation updates.

If you haven’t used git yet, consider setting up a git account now and playing around with it. You can get a free account at github.com, and if you follow projectblacklight you can choose to be notified of any changes that occur to that project. If you’re currently on our subversion commit changes list, github services will be replacing that list, and I’ll send out a separate email about how to make sure you continue receiving notifications of code commits. If you need an introduction to using git, I highly recommend Pro Git by Scott Chacon, which is available both in print and online at http://progit.org/.

Thanks for being such a fantastic community!

Bess Sadler
release manager for project blacklight

Dear Blacklight community,

One of the goals that I and the other project committers have for project blacklight is to strike a healthy balance between project inclusiveness and the ability to produce high quality software in a short time period, which is easier with a small group of people. Currently, the project committers have a weekly phone call where we assign tasks, check on progress, hash out bug fixes, and decide on features for new releases, as well as discuss ideas for project management and coordination. This is a great system from the point of view of developing software, but lately we’ve been feeling that it doesn’t pay enough attention to the inclusiveness side of this project’s goals.

An idea we’ve been tossing around is to have a monthly skype call where anyone could participate. This might be of interest to you if you have questions or concerns that you want to discuss with the project’s programmers, or if you have a feature request you want to advocate for, or if you just want to have more input in the decision making for the project.

Our skype calls are usually on Fridays at 1pm North American Eastern time. I propose that our first all-comers call be October 9 at this usual time. If you’d like to participate:

1. Email me your skype id and let me know you want to be included

2. Before the call, please make sure you have headphones, a microphone, and the fastest internet service available to you (e.g., if you have a choice, please use a land line at your office, not the wireless at the coffeeshop). The more people we have in a skype call the more difficult it is to speak, and one bad audio setup can ruin things for everyone.

As we get closer to the date, I’ll send out a reminder email and we can start forming an agenda.

What do we think, community? Is this a good idea?

Bess

The 2.3 release has just been uploaded. We’re now releasing both a demo app, for people who are just getting started or doing a fresh installation, and a plugin, for people who want to update an existing installation or plug blacklight search and discovery into another rails app. Be sure to also read the updated installation instructions and rdocs.

Here are the highlights of this release (paraphrased from the official jira-generated release notes):

1. installation instructions are now maintained in rdoc, and transformed to html with hanna. This makes our docs much more attractive and easy to search than they were previously. You can see the outcome at http://blacklight.rubyforge.org, where we publish our auto-generated rdocs.
2. The demo app now uses solrmarc for indexing marc records. The previous ruby-based marc indexer is still there, but the instructions direct users to the solrmarc-based rake task. Generally, we don’t want to duplicate effort with solrmarc. It makes sense for that project to handle all our marc indexing needs, and we’ll just maintain a rake task and a config file for the demo project.
3. Better graphic design for the demo app! You can see this in action at http://demo.projectblacklight.org
4. Better error handling
5. Capistrano deploy script for the demo app, which can be adapted for local deployment
6. We merged the home controller into the catalog controller so removing all your searches now takes you back to the front page
7. RefWorks and EndNote export
8. Email and SMS texting of records
9. Required gems are now vendored (i.e., distributed with the download), which we hope will make installation easier

Give this release a try and let us know what you think! As always, please join us on the mailing list if you have questions.

The 2.1 release is out the door and ready for download. You can download it here and view the release notes here.

Highlights of this release include:

• Several bug fixes
• More robust testing for the plugin (tests for the plugin no longer rely on an external solr index)
• Better adherence to W3C accessibility guidelines
• Savable search history
• APA/MLA citations
• OpenSearch support
• Fielded search
• Sortable search results

The Blacklight Development mail list has moved from its old home on rubyforge to Google Groups.

To join, just go to the Blacklight Development group homepage and sign up. Or click on the mail list link in the sidebar to be taken to the project homepage.

There is a spiffy new 2.0 release out in the world now, and you can download it here and release notes are here. This is our first release since refactoring for the plugin architecture, so we thought it deserved a major number bump. Also, we’ve re-arranged the subversion tree so current development is now happening in trunk. Docs on the wiki are updated accordingly. The rdocs from the Blacklight plugin are visible online now too, here. Please have a look and give us some feedback!

There’s a JIRA instance up (http://blacklightopac.org:8080/jira/browse) that can be used for bug reports, feature requests, etc. We currently have things categorized into “release 2.0″ and “release 2.1″ … but that is likely to evolve as the project grows.

We have also decided to have the Roadmap in a single place: in JIRA.

http://blacklightopac.org:8080/jira/browse/CODEBASE?report=com.atlassian.jira.plugin.system.project%3Aroadmap-panel

I’ve been thinking about the best way to put Stanford’s blacklight application into our own source control. I see three options:

1. Include the plugins in local source control.
Pro: installing application from our source control is simple.
Con: Using local source control for the plugins makes it challenging to update the plugin code from the external repositories.

2. don’t include the plugins in local source control.
Pro: You can update the plugins using RoR built in scripts: ruby script/plugin update (external_svn_url)
Con: Extra steps to install local application.

Note: if doing this: Do NOT put the empty “(yourapp)/vendor/plugins” directory into your local application’s subversion.**

3. use svn:externals for the plugins.
Pro: You’ll get the plugin code updates automagically, and you don’t have to muck about with them in your local subversion
Con: You don’t have control over what version of the plugin you’re getting – it’s going to grab the latest from the external repos. This can be bad, specially when you’re using unstable code. Also: what if the plugins are in a git repository??

For the record, I chose 2. Post a comment to this blog post if you have input.

I just finished a talk on Blacklight at code4lib and it went really well. Apparently people really like our notion of distributing BL as an overloadable plugin, because there was some spontaneous applause when I mentioned it. You can view the slides here: http://code4lib.org/files/blacklight_code4lib09.pdf. There’s going to be a breakout session this afternoon, and I’ll post about that, too. –Bess

We now have a wiki page with a rough cut at work to be done in the next few months.

http://blacklightopac.org:8080/jira/browse/CODEBASE?report=com.atlassian.jira.plugin.system.project%3Aroadmap-panel

And … I’ve started a wiki about testing. Right now it’s a way too verbose thing … but we’ll improve on it.:

http://wiki.blacklightopac.org/doku.php?id=testing

We now have a publicly accessible issue tracking system available at http://blacklightopac.org:8080/jira. Anyone who would like to report issues, request new features, help us track down bugs or get involved with development, please make yourself an account and jump right in.

There’s also the start of a roadmap for release 2.0 available here. Watch that space for additions as we start to firm up what features we want to commit to for 2.0. Suggestions from the community?

The big news for Blacklight in the past month has been Matt Mitchell’s excellent Blacklight plugin that allows clean separation between site specific changes and the open source project code.

A problem faced by many open source applications whose users also want to customize them is that local code gets out of sync with the open source project code and upgrades become a headache. I think we’re well on the way to avoiding that problem for Blacklight. Using the Rails Engines plugin, Blacklight is now available as a generic plugin application that offers most of the functionality of the UVA Blacklight instance. When you put this plugin into an empty rails application, you can overload behaviors as well as the look and feel for your local installation, while keeping the open source project code separate. This will make it easy to upgrade the core functionality when new releases come out. With the engines plugin structure, local changes aren’t entangled with the public project, so you won’t need to comb through the project to find your localized code.

We’re still in the process of writing documentation that will show people how to create their own look and feel for Blacklight, but if you’re interested in trying Blacklight you might want to start with a demo application. You can see what this will look like after installation here, and you can read installation instructions here. I hope you’ll try it and give us some feedback about the application and the installation process.