blacklight_range_limit 8.4.0 → 9.0.0.beta1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 510a2e212fd11cacd9e7a83be02dec8ddec4f5e3e551fb64187f022825ae2661
-  data.tar.gz: c7505814e1172ff021da4ecd65fc7085639771138cf557cf6343707cad9ad577
+  metadata.gz: 8f262cbfeff305e3cd1567ffcd35b90e647d3afd3558b95cf9a2f739381b20ff
+  data.tar.gz: ddfa401cafc2c1dac75d06c13a2214c7abf2f96fce4dd1421bc0c4a343e0ad8f
 SHA512:
-  metadata.gz: 5c6ef8dd3df728ab8790ddb050ab05f4ff1d72053410af3a138891160f9cb00d287d341586463e6e91081ea271f6c2afaa08773420177d3d455f966fa366b789
-  data.tar.gz: 8c91836e3eaa68af79f7192d18a81a1c0d57f3d6f8d49d0a1fa278ffc657dc597bfe01294e12e87f7954972c3a9f47ac1cd8a479a9279292b81d20cb637de791
+  metadata.gz: 914a2910f0b99f6a9223cbdb32779c7a862d19a4d0d0c3ca973383c90e45e05fcf04fdc928ed3a7f7c0222ee87924071ae2af9cd4f219479adabd2601634d2f0
+  data.tar.gz: 8a11a84d0c57be9a3036518d284bd2f698e70303fbfcde30ad2d3ee66c4018ae15543df19c6d010423b724fb1452998faa3129682a6ce13f7300746e0a68e5b8

data/.github/workflows/ruby.yml

@@ -9,37 +9,131 @@ name: CI
 
 on:
   push:
-    branches: [ main ]
+    branches: [main]
   pull_request:
-    branches: [ main ]
+    branches: [main]
 
 jobs:
   test:
     runs-on: ubuntu-latest
-    name: test (ruby ${{ matrix.ruby }} / rails ${{ matrix.rails_version }})
+    name: test (${{ matrix.blacklight_version && format('bl {0} / ', matrix.blacklight_version) }}rails ${{ matrix.rails_version }} / rb ${{ matrix.ruby }} ${{ matrix.additional_name }})
     strategy:
+      fail-fast: false
       matrix:
-        ruby: [2.7, '3.0']
-        rails_version: ['6.1.7.1', '7.0.4.1']
-        additional_engine_cart_rails_options: ['']
+        # We have SEVERAL axes of difference we support.
+        #
+        #   * Blacklight: 7, 8, or 9
+        #   * Rails: 7 or 8
+        #   * sprockets or propshaft(with cssbundling-rails sass)
+        #   * importmap-rails or esbuild  (each with sprockets or importmaps)
+        #
+        # We should work with almost every combo of these (even though BL itself
+        # doesn't officially support every one), but we don't test with every one,
+        # that'd be too much. Plus BL can't *generate* every one even though it
+        # can be made to work with every one. We test with some good significant
+        # representative samples.
+
         include:
-        - ruby: '3.2'
-          rails_version: '7.0.4.1'
-        - ruby: '3.1'
-          rails_version: '7.0.4.1'
-        - ruby: '3.0'
-          rails_version: '7.0.4.1'
+          # BLACKLIGHT EDGE, can test with Rails 8 beta, importmap and esbuild
+          #
+
+          - rails_version: "~> 8.0.0"
+            blacklight_version: '{ "git": "https://github.com/projectblacklight/blacklight.git" }'
+            ruby: "3.3"
+            additional_name: "/ importmap-rails"
+            additional_engine_cart_rails_options: "--css=bootstrap"
+          - rails_version: "~> 8.0.0"
+            blacklight_version: '{ "git": "https://github.com/projectblacklight/blacklight.git" }'
+            ruby: "3.3"
+            additional_name: "/ esbuild"
+            additional_engine_cart_rails_options: "--css=bootstrap --javascript=esbuild"
+
+
+
+          # BLACKLIGHT 8, can test with use importmaps and esbuild
+          #
+
+          - rails_version: "7.2.1"
+            blacklight_version: "~> 8.0"
+            ruby: "3.3"
+            additional_name: "/ importmap-rails, sprockets"
+          - rails_version: "7.2.1"
+            blacklight_version: "~> 8.0"
+            ruby: "3.3"
+            additional_name: "/ importmap-rails, propshaft"
+            additional_engine_cart_rails_options: "-a propshaft --css=bootstrap"
+          - rails_version: "7.2.1"
+            blacklight_version: "~> 8.0"
+            ruby: 3.3
+            additional_engine_cart_rails_options: "-a propshaft --javascript=esbuild --css=bootstrap"
+            additional_name: "/ esbuild, propshaft"
+
+            # We can't currently test Blacklight 8 in a few situations we'd like to.
+            #
+            # * Blacklight 8 can't easily generate an app with Rails 7 and sprockets and esbuild
+            #   (the default layout won't be right), although I think it should work fine.
+            #
+            # * Can't test with unreleaed Blacklight main and esbuild because the blacklight-frontend
+            #   npm package doens't work from git checkout.  So currently can't test with Rails8
+            #   and esbuild.
+
+
+
+          # BLACKLIGHT 7, only test with esbuild, not sure if it supports importmaps, it won't generate it
+
+          - rails_version: "7.2.1"
+            blacklight_version: "~> 7.0"
+            ruby: "3.3"
+            additional_engine_cart_rails_options: "--javascript=esbuild"
+            additional_name: "/ esbuild, sprockets"
+          - rails_version: "7.2.1"
+            blacklight_version: "~> 7.0"
+            ruby: "3.3"
+            additional_engine_cart_rails_options: "--javascript=esbuild --css=bootstrap  -a propshaft"
+            additional_name: "/ esbuild, propshaft"
+
+          - rails_version: "7.1.4"
+            blacklight_version: "~> 7.0"
+            ruby: "3.2"
+            additional_engine_cart_rails_options: "--javascript=esbuild"
+            additional_name: "/ esbuild, sprockets"
+
+          - rails_version: "7.0.8.4"
+            blacklight_version: "~> 7.0"
+            ruby: "3.1"
+            additional_engine_cart_rails_options: "--javascript=esbuild"
+            additional_name: "/ esbuild, sprockets"
+
+
+
+
+
     env:
-      BLACKLIGHT_VERSION: "~> 7.0" # only test on BL 7 for now
+      BLACKLIGHT_VERSION: ${{ matrix.blacklight_version || '~> 8.0' }}
       RAILS_VERSION: ${{ matrix.rails_version }}
-      ENGINE_CART_RAILS_OPTIONS: "--skip-git --skip-listen --skip-spring --skip-keeps --skip-action-cable --skip-coffee --skip-test ${{ matrix.engine_cart_rails_options }}"
+      ENGINE_CART_RAILS_OPTIONS: "--skip-git --skip-listen --skip-spring --skip-keeps --skip-coffee --skip-test ${{ matrix.additional_engine_cart_rails_options }}"
     steps:
-    - uses: actions/checkout@v3
-    - name: Set up Ruby
-      uses: ruby/setup-ruby@v1
-      with:
-        ruby-version: ${{ matrix.ruby }}
-    - name: Install dependencies
-      run: bundle install
-    - name: Run tests
-      run: bundle exec rake ci
+      - uses: actions/checkout@v4
+      - name: Set up Ruby
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: ${{ matrix.ruby }}
+          bundler: "latest"
+
+      - name: Install dependencies
+        run: bundle install
+
+      # Try to cache solr dist download, which may not save us much time,
+      # but hopes to save us from being throttled/blocked on some runs by
+      # apache foundation servers unhappy that we're downloading the dist zip
+      # so much.
+      - name: Cache solr install
+        uses: actions/cache@v3
+        with:
+          # these paths specified in .solr_wrapper.yml:
+          path: |
+            ci_dl_solr_dist
+          key: ${{ runner.os }}-solr-${{ hashFiles('.solr_wrapper.yml') }}
+
+      - name: Run tests
+        run: bundle exec rake ci

data/.gitignore

@@ -23,7 +23,9 @@ Gemfile.lock
 
 /spec/internal
 .internal_test_app
+spec/examples.txt
 /jetty
 /pkg
 /tmp
 /.bundle
+/node_modules

data/.solr_wrapper.yml

@@ -1,6 +1,14 @@
 # Place any default configuration for solr_wrapper here
+#
+# We try to use a cacheable and cached location for solr at tmp/solr_dist
+# in Github Actions CI, to avoid excessive downloads from
+# apache (which also get sometimes blocked/rate-limited)
+
 port: 8983
 verbose: true
+version: 9.6.1
+  <% ENV['CI'] && FileUtils.mkdir_p('ci_dl_solr_dist') %>
+download_dir: <%= 'ci_dl_solr_dist' if ENV['CI'] %>
 collection:
   dir: solr/conf/
   name: blacklight-core

data/Gemfile

@@ -1,4 +1,5 @@
 # frozen_string_literal: true
+require 'json'
 
 source 'https://rubygems.org'
 
@@ -14,7 +15,12 @@ end
 # a blacklight version other than the latest allowed by gemspec, to get
 # tests to pass, or to test on older BL still supported here.
 if ENV['BLACKLIGHT_VERSION']
-  gem "blacklight", ENV['BLACKLIGHT_VERSION']
+  # allow direct git and other with serialized json kw args
+  if ENV['BLACKLIGHT_VERSION'].start_with?("{")
+    gem "blacklight", **JSON.parse(ENV['BLACKLIGHT_VERSION'])
+  else
+    gem "blacklight", ENV['BLACKLIGHT_VERSION']
+  end
 end
 
 # BEGIN ENGINE_CART BLOCK

data/README.md

@@ -8,151 +8,148 @@ BlacklightRangeLimit:  integer range limiting and profiling for Blacklight appli
 
 The BlacklightRangeLimit plugin provides a 'facet' or limit for integer fields, that lets the user enter range limits with a text box or a slider, and also provides area charts giving a sense of the distribution of values (with drill down).
 
-The primary use case of this plugin is for 'year' data, but it should work for any integer field. It may not work right for negative numbers, however.
+The primary use case of this plugin is for 'year' data, but it should work for any integer field.
 
 Decimal numbers and Dates are NOT supported; they theoretically could be in the future, although it gets tricky.
 
 
 # Requirements
 
-A Solr integer field. Depending on your data, it may or may not be advantageous to use a tint (trie with non-zero precision) type field.
+* A Solr integer field. It might be advantageous to use an IntPointField.
 
-## Note on solr field types
+* Javascript requires you to be using either rails-importmaps or a package.json-based builder like jsbundling-rails or vite-ruby.  Legacy "sprockets-only" is not supported, however propshaft or sprockets can be used as your base asset pipeline.
 
-If all your integers are the same number of digits, you can use just about any solr type, including string/type, and all will be well. But if your integers vary in digits, strings won't sort correctly, making your numbers behave oddly in partitions and limits. This is also true if you use a pre-1.4 "integer"/pint/solr.IntField  field -- these are not "sortable".
+* Blaklight 7.0+.  Rails 7.0+
 
-You need to use a "sortable" numeric-type field. In Solr 1.4, the standard "int"/solr.TrieIntField should work fine and is probably prefered. For some distributions of data, it may be more efficient to use "tint" (solr.TrieIntField with non-zero precision).
-
-The pre Solr 1.4 now deprecated sint or slong types should work fine too.
 
 # Installation
 
-Current 5.x version of `blacklight_range_limit` work with `blacklight` 5.x -- we now synchronize the _major version number_ between `blacklight` and `blacklight_range_limit`.  `blacklight_range_limit` 2.1 is the last version believed to work with blacklight 4.x or possibly blacklight 3.x.
-
 Add
 
     gem "blacklight_range_limit"
 
-to your Gemfile. Run "bundle install".
+to your Gemfile. Run `bundle install`.
 
-Then run
+Run `rails generate blacklight_range_limit:install`
 
-    rails generate blacklight_range_limit:install
+### Manual Javascript setup is not hard
 
-This will install some asset references in your application.js and application.css.
+The installer could have trouble figuring out how to add Javascript to your particular setup. In the end, all you need is `blacklight-range-limit` either importmap-pinned (with it's chart.js dependency), or added to your package.json, and then, in a file that has access to the `Blacklight` import:
 
-# Configuration
+    import BlacklightRangeLimit from "blacklight-range-limit";
+    BlacklightRangeLimit.init({ onLoadHandler: Blacklight.onLoad });
 
-You have at least one solr field you want to display as a range limit, that's why you've installed this plugin. In your CatalogController, the facet configuration should look like:
+A package.json might include:
 
-```ruby
-config.add_facet_field 'pub_date', label: 'Publication Year', **default_range_config
 ```
+"blacklight-range-limit": "^9.0.0",
+```
+(direct to git references also supported in package.json)
 
-You should now get range limit display. More complicated configuration is available if desired, see Range Facet Configuration below.
+importmap.rb pins might look like:
 
+```
+pin "chart.js", to: "https://ga.jspm.io/npm:chart.js@4.2.0/dist/chart.js"
+pin "@kurkle/color", to: "https://ga.jspm.io/npm:@kurkle/color@0.3.2/dist/color.esm.js"
+```
 
-You can also configure the look and feel of the Flot chart using the jQuery .data() method. On the `.blrl-plot-config` or `.facet-limit` container you want to configure, add a Flot options associative array (documented at http://people.iola.dk/olau/flot/API.txt) as the `plot-config` key. The `plot-config` key to set the `plot-config` key on the appropriate `.blrl-plot-config` or `.facet-limit` container. In order to customize the plot colors, for example, you could use this code:
+For import map pins, note:
+* The standard "locally vendored" importmap-rails setup is not working with chart.js at the time of this writing, so you need to pin to CDN as above.
+* versions in importmap pins will have to be updated manually if you want to upgrade.
 
-```javascript
-$('.blacklight-year_i').data('plot-config', {
-    selection: { color: '#C0FF83' },
-    colors: ['#ffffff'],
-    series: { lines: { fillColor: 'rgba(255,255,255, 0.5)' }},
-    grid: { color: '#aaaaaa', tickColor: '#aaaaaa', borderWidth: 0 }
-});
+### Unreleased version?
+
+If you'd like to use an unrelased version from git, just add that to your Gemfile in the usual way.
+
+importmap-rails use should then Just Work.
+
+package.json-based use will additionally need to point to the matching unreleaesd version in git in package.json, eg `yarn add blacklight-range-limit@git+https://github.com/projectblacklight/blacklight_range_limit.git#branch_name_or_commit_sha`. Still simple.
+
+
+# Facet Configuration
+
+You have at least one solr field you want to display as a range limit, that's why you've installed this plugin. In your CatalogController, the facet configuration should look like:
+
+```ruby
+config.add_facet_field 'pub_date', label: 'Publication Year', range: true
 ```
-You can add this configuration in app/assets/javascript/application.js, or anywhere else loaded before the blacklight range limit javascript.
+
+You should now get range limit display. More complicated configuration is available if desired, see Range Facet Configuration below.
 
 ## A note on AJAX use
 
 In order to calculate distribution segment ranges, we need to first know the min and max boundaries. But we don't really know that until we've fetched the result set (we use the Solr Stats component to get min and max with a result set).
 
-So, ordinarily, after we've gotten the result set, only then can we calculate the segment ranges, and then we need to do another Solr request to actually fetch the segment range counts.
+So, ordinarily, after we've gotten the result set, an additional round trip to back-end and solr will happen, with min max identified, to fetch segments.
 
-The plugin uses an AJAX request on the result page to do this. This means that for every application results display that includes any values at all in your range field, your application will get a second AJAX http request, and make a second solr request.
-
-If you'd like to avoid this, you can turn off segment display altogether with the :segment option below; or you can set :assumed_boundaries below to use fixed boundaries for not-yet-limited segments instead of taking boundaries from the result set.
+If you'd like to avoid this, you can set :assumed_boundaries below to use fixed boundaries for not-yet-limited segments instead of taking boundaries from the result set. Or you can disable the segment behavior by setting `chart_js` and `textual_facets` both to false.
 
 Note that a drill-down will never require the second request, because boundaries on a drill-down are always taken from the specified limits.
 
 
 ## Range Facet Configuration
 
-Instead of simply passing "true", you can pass a hash with additional configuration. Here's an example with all the available keys, you don't need to use them all, just the ones you want to set to non-default values.
+There are some additional configuration options that can be passed in facet config in the `range_config` key. You can pass some or all of them like this:
 
 ```ruby
-config.add_facet_field 'pub_date', label: 'Publication Year',
-                       range: {
-                         num_segments: 6,
-                         assumed_boundaries: [1100, Time.now.year + 2],
-                         segments: false,
-                         maxlength: 4
-                       }
+config.add_facet_field 'pub_date', label: 'Publication Year', range_config: {
+       num_segments: 6,
+       assumed_boundaries: [1100, Time.now.year + 2],
+       segments: true,
+       chart_js: true,
+       textual_facets: true,
+       textual_facets_collapsible: true,
+       chart_segment_border_color: "rgba(0,0,0, 0.5)",
+       chart_segment_bg_color: "#ccddcc",
+       chart_aspect_ratio: "2"
+    }
+)
 ```
 
 * **:num_segments** :
   * Default 10. Approximately how many segments to divide the range into for segment facets, which become segments on the chart. Actual segments are calculated to be 'nice' values, so may not exactly match your setting.
 * **:assumed_boundaries** :
   * Default null. For a result set that has not yet been limited, instead of taking boundaries from results and making a second AJAX request to fetch segments, just assume these given boundaries. If you'd like to avoid this second AJAX Solr call, you can set :assumed_boundaries to a two-element array of integers instead, and the assumed boundaries will always be used. Note this is live ruby code, you can put calculations in there like Time.now.year + 2.
-* **:segments** :
-  * Default true. If set to false, then distribution segment facets will not be loaded at all.
-* **:maxlength** :
-  * Default 4. Changes the value of the `maxlength` attribute of the text boxes, which determines how many digits can be entered.
-
-## Javascript dependencies
+* **chart_js**:
+  * Default true. If false, the Javascript chart is not loaded, you can still get textual facets for bucket with `textual_facets` config.
+* **textual_facets**: Default true. Should we show textual facet list too? Universal design
+  for accessibility, may have accessibilty concerns to turn off.
+* **textual_facets_collapsible**: Put the textual facets in a collapse/expand
+  disclosure. If you set chart_js to false, may make sense to set this to false too, to have
+  textual facets only instead of chart?
+* **chart_segment_border_color** / **chart_segment_bg_color** :
+  * Set colors for the edge and fill of the segment bars in the histogram.
+* chart_aspect_ratio: for chart.js, will fill available width then this determines size of chart. defaults to 2
 
-The selectable histograms/barcharts are done with Javascript, using [Flot](http://code.google.com/p/flot/). Flot requires JQuery, as well as support for the HTML5 canvas element. For the slider, [bootstrap-slider](http://www.eyecon.ro/bootstrap-slider/) is used (bootstrap-slider is actually third party, not officially bootstrap). Flot and bootstrap-slider are both directly included in blacklight_range_limit in vendor, rather than referenced as dependencies.
 
-The blacklight_range_limit installer will add `require 'blacklight_range_limit'` to your `application.js` sprockets manifest. This will include flot, bootstrap-slider, and the blacklight_range_limit glue JS.
-
-Both flot and blacklight_range_limit's own JS depend on JQuery; the host app is expected to include JQuery; a default Blacklight-generated app already does. (Jquery 1, 2, or 3 should work)
-
-If you don't want any of this gem's JS, you can simply remove the `require 'blacklight_range_limit'` line from your application.js, and hack something else together yourself.
+## Javascript dependencies
 
-## Touch?
+We use [chart.js](https://www.chartjs.org/) to draw the chart. It has one dependency of it's own. These need to be either pinned with importmap-rails, or used via the chart.js npm package and an npm-package-based bundler.
 
-For touch screens, one wants the UI to work well. The slider used is
-[bootstrap_slider](http://www.eyecon.ro/bootstrap-slider/), which says if you add
-Modernizr to your page, touch events will be supported. We haven't tested it
-ourselves yet.
+There is **no CSS** needed.
 
-Also not sure how well the flot select UI works on a touch screen. The slider
-is probably the best touch UI anyway, if it can be made to work well.
+## Upgrading from blacklight-range-limit 8.x to 9.x
 
-## JavaScript Customization
+All back-end configuration should be backwards compatible.
 
-There are two main types of JavaScript implemented for BlacklightRangeLimit:
- - Initialization and refresh of Range Limit plugin based off of events
- - Range Limit plugin functionality called from event listeners
+You will need to change how you load JS. (There is no longer any blacklight_range_limit CSS to load).
 
- The second class of range limit functionality is customizable in your local application by overriding the specified function.
+You will need to be using either importmap-rails or a package.json-based javascript bunder (jsbundling-rails or vite) to deliver JS to your app. Legacy sprockets-only is not supported.
 
- A simple example of this is overriding the display ratio used to create the histogram
+Then, remove ALL existing (sprockets) references to blacklight_range_limit in your JS or CSS pipelines.
 
- ```javascript
- BlacklightRangeLimit.display_ratio = 1
-```
+And run `rails g blacklight_range_limit:assets` -- or manually set up the JS for unusual setups (such as vite-rails), see above at <a href="#installation">Installation</a>.
 
-This will now create a square histogram.
+For an unreleased version from git -- the installer is not presently capable of installing
+that, but simply add the unreleased version of the gem to your Gemfile.
 
-Not only these variables and functions be customized, you can call them based off of custom events in your application.
-
-```javascript
-$('.custom-class').on('doSomething', function() {
-  BlacklightRangeLimit.checkForNeededFacetsToFetch();
-  $(".range_limit .profile .range.slider_js").each(function() {
-    BlacklightRangeLimit.buildSlider(this);
-  });
-});
-```
 
 # Tests
 
 Test coverage is not great, but there are some tests, using rspec.  Run `bundle exec rake ci` or just `bundle exec rake` to seed and
-start a demo jetty server, build a clean test app, and run tests.
+start a demo solr server, build a clean test app, and run tests.
 
-Just `bundle exec rake spec` to just run tests against an existing test app and jetty server.
+Just `bundle exec rake spec` to just run tests against an existing test app and solr server.
 
 ## Local Testing
 If you want to iterate on a test locally and do not want to rebuild the
@@ -173,9 +170,3 @@ Once you are done iterating on your test you will need to stop the application s
 
 run `npm publish` to push the javascript package to https://npmjs.org/package/blacklight-range-limit
 
-# Possible future To Do
-
-* StatsComponent replacement. We use StatsComponent to get min/max of result set, as well as missing count. StatsComponent is included on every non-drilldown request, so ranges and slider can be displayed. However, StatsComponent really can slow down the solr response with a large result set. So replace StatsComponent with other strategies. No ideal ones, we can use facet.missing to get missing count instead, but RSolr makes it harder than it should be to grab this info. We can use seperate solr queries to get min/max (sort on our field, asc and desc), but this is more complicated, more solr queries, and possibly requires redesign of AJAXy stuff, so even a lone slider can have min/max.
-* tests
-* In cases where an AJAX request is needed to fetch more results, don't trigger the AJAX until the range facet has actually been opened/shown. Currently it's done on page load.
-* If :assumed_boundaries ends up popular, we could provide a method to fetch min and max values from entire corpus on app startup or in a rake task, and automatically use these as :assumed_boundaries.

data/Rakefile

@@ -11,6 +11,11 @@ task :default => :ci
 desc "Run specs"
 RSpec::Core::RakeTask.new
 
+# rspec hooks up spec task with spec:prepapre dependency. But we need to make sure
+# it gets called *within test app* so for jsbundling-rails JS is properly built.
+# So we add our custom as a dependency.
+task spec: ["test:spec:prepare"]
+
 task ci: ['engine_cart:generate'] do
   SolrWrapper.wrap do |solr|
     solr.with_collection(name: 'blacklight-core', dir: File.join(File.expand_path(File.dirname(__FILE__)), "solr", "conf")) do
@@ -20,7 +25,17 @@ task ci: ['engine_cart:generate'] do
   end
 end
 
+
 namespace :test do
+  namespace :spec do
+    desc "call task spec:prepare within test app"
+    task :prepare do
+      within_test_app do
+        system "bin/rake spec:prepare"
+      end
+    end
+  end
+
   desc "Put sample data into solr"
   task seed: ['engine_cart:generate'] do
     within_test_app do
@@ -30,6 +45,22 @@ namespace :test do
     end
   end
 
+  desc "run just solr, useful for local tests"
+  task :solr, [:rails_sever_args] do |_t, args|
+    unless File.exist? EngineCart.destination
+      Rake::Task['engine_cart:generate'].invoke
+    end
+
+    SolrWrapper.wrap(port: '8983') do |solr|
+      solr.with_collection(name: 'blacklight-core', dir: File.join(File.expand_path(File.dirname(__FILE__)), "solr", "conf")) do
+        Rake::Task['test:seed'].invoke
+        # sleep forever, make us cntrl-c to get out
+        puts "solr is running on port 8983, ctrl-c to exit..."
+        system "while true; do sleep 10000; done"
+      end
+    end
+  end
+
   desc 'Run Solr and Blacklight for interactive development'
   task :server, [:rails_server_args] do |_t, args|
     if File.exist? EngineCart.destination

data/VERSION

@@ -1 +1 @@
-8.4.0
+9.0.0.beta1