Note: automatic revert not possible.

Solr_wrapper was never fully removed and the docker based solr solution
was never documented. This PR restores the solr_wrapper approach for CI.

Fixes #2195
Fixes #2183
Fixes #2231

This reverts commit 0759cd5.

Solr_wrapper was never fully removed and the docker based solr solution
was never documented. This PR restores the solr_wrapper approach for CI.

Fixes #2195
Fixes #2183
Fixes #2231

Fixes #2195
Fixes #2231
Closes #2256

In this way, we are using docker-compose for development and testing of the Blacklight gem itself, not for downstream purposes such as generation of new Blacklight applications, which will continue to use solr_wrapper.

This is currently a draft PR, intended to supersede #2256. This is not yet done, though, because...

It is not clear to me where information like this is currently documented. The README is short and sweet, and for this reason I suspect it is not a good place for such internal development documentation to live. Other options include `CONTRIBUTING.md`, but that is more focused on higher-level contribution process than particular technical steps.

Note, I also don't think the Quickstart is the right place, so this ticket has nothing to do with #2183, which I think we should either close as a `wontfix` per [my comment](#2183 (comment)) or discuss what the right way to move forward is particularly w/r/t how much we continue to generate for downstream BL apps: *i.e.*, if we don't give them a working SolrWrapper, do we generate/ship a working docker-compose configuration? Or do we get out of that business entirely? This is beyond the scope of this PR.

For this reason, perhaps the best place is somewhere on the [project wiki](https://github.com/projectblacklight/blacklight/wiki). Happy to take suggestions on this.

Note that this PR changes the `blacklight:server` rake task to use `docker-compose` for Solr but I was unable to see this working---with Ruby 2.6 and Rails 6, but other combinations will yield different results---because when Blacklight uses EngineCart to generate the test app, there's a problem with webpack(er). If you generate without the `--skip-webpack-install` flag being passed to the `rails new` command, the Rails webpack generator runs and fails because the dependency is not declared. If you skip webpack installation, Rails generates an app that still contains `webpacker` in its Gemfile, and it's a multi-step process to strip out webpack(er) and use Sprockets in its stead ([1](http://mitrev.net/ruby/2019/12/27/rails-6-without-webpack/), [2](https://www.reddit.com/r/rails/comments/b0goct/webpacker_for_non_js_people/eih2930/), [3](https://stackoverflow.com/a/58518795)). That said, I did not alter this behavior or attempt to fix the underlying problem since it is orthogonal to how we spin up Solr for CI/testing of Blacklight.

Fixes #2195
Fixes #2231
Closes #2256

In this way, we are using docker-compose for development and testing of the Blacklight gem itself, not for downstream purposes such as generation of new Blacklight applications, which will continue to use solr_wrapper.

This is currently a draft PR, intended to supersede #2256. This is not yet done, though, because...

It is not clear to me where information like this is currently documented. The README is short and sweet, and for this reason I suspect it is not a good place for such internal development documentation to live. Other options include `CONTRIBUTING.md`, but that is more focused on higher-level contribution process than particular technical steps.

Note, I also don't think the Quickstart is the right place, so this ticket has nothing to do with #2183, which I think we should either close as a `wontfix` per [my comment](#2183 (comment)) or discuss what the right way to move forward is particularly w/r/t how much we continue to generate for downstream BL apps: *i.e.*, if we don't give them a working SolrWrapper, do we generate/ship a working docker-compose configuration? Or do we get out of that business entirely? This is beyond the scope of this PR.

For this reason, perhaps the best place is somewhere on the [project wiki](https://github.com/projectblacklight/blacklight/wiki). Happy to take suggestions on this.

Note that this PR changes the `blacklight:server` rake task to use `docker-compose` for Solr but I was unable to see this working---with Ruby 2.6 and Rails 6, but other combinations will yield different results---because when Blacklight uses EngineCart to generate the test app, there's a problem with webpack(er). If you generate without the `--skip-webpack-install` flag being passed to the `rails new` command, the Rails webpack generator runs and fails because the dependency is not declared. If you skip webpack installation, Rails generates an app that still contains `webpacker` in its Gemfile, and it's a multi-step process to strip out webpack(er) and use Sprockets in its stead ([1](http://mitrev.net/ruby/2019/12/27/rails-6-without-webpack/), [2](https://www.reddit.com/r/rails/comments/b0goct/webpacker_for_non_js_people/eih2930/), [3](https://stackoverflow.com/a/58518795)). That said, I did not alter this behavior or attempt to fix the underlying problem since it is orthogonal to how we spin up Solr for CI/testing of Blacklight.

Fixes #2195
Fixes #2231
Closes #2256

In this way, we are using docker-compose for development and testing of the Blacklight gem itself, not for downstream purposes such as generation of new Blacklight applications, which will continue to use solr_wrapper.

This is currently a draft PR, intended to supersede #2256. This is not yet done, though, because...

It is not clear to me where information like this is currently documented. The README is short and sweet, and for this reason I suspect it is not a good place for such internal development documentation to live. Other options include `CONTRIBUTING.md`, but that is more focused on higher-level contribution process than particular technical steps.

Note, I also don't think the Quickstart is the right place, so this ticket has nothing to do with #2183, which I think we should either close as a `wontfix` per [my comment](#2183 (comment)) or discuss what the right way to move forward is particularly w/r/t how much we continue to generate for downstream BL apps: *i.e.*, if we don't give them a working SolrWrapper, do we generate/ship a working docker-compose configuration? Or do we get out of that business entirely? This is beyond the scope of this PR.

For this reason, perhaps the best place is somewhere on the [project wiki](https://github.com/projectblacklight/blacklight/wiki). Happy to take suggestions on this.

Note that this PR changes the `blacklight:server` rake task to use `docker-compose` for Solr but I was unable to see this working---with Ruby 2.6 and Rails 6, but other combinations will yield different results---because when Blacklight uses EngineCart to generate the test app, there's a problem with webpack(er). If you generate without the `--skip-webpack-install` flag being passed to the `rails new` command, the Rails webpack generator runs and fails because the dependency is not declared. If you skip webpack installation, Rails generates an app that still contains `webpacker` in its Gemfile, and it's a multi-step process to strip out webpack(er) and use Sprockets in its stead ([1](http://mitrev.net/ruby/2019/12/27/rails-6-without-webpack/), [2](https://www.reddit.com/r/rails/comments/b0goct/webpacker_for_non_js_people/eih2930/), [3](https://stackoverflow.com/a/58518795)). That said, I did not alter this behavior or attempt to fix the underlying problem since it is orthogonal to how we spin up Solr for CI/testing of Blacklight.

Fixes #2195
Fixes #2231
Closes #2256

In this way, we are using docker-compose for development and testing of the Blacklight gem itself, not for downstream purposes such as generation of new Blacklight applications, which will continue to use solr_wrapper.

This is currently a draft PR, intended to supersede #2256. This is not yet done, though, because...

It is not clear to me where information like this is currently documented. The README is short and sweet, and for this reason I suspect it is not a good place for such internal development documentation to live. Other options include `CONTRIBUTING.md`, but that is more focused on higher-level contribution process than particular technical steps.

Note, I also don't think the Quickstart is the right place, so this ticket has nothing to do with #2183, which I think we should either close as a `wontfix` per [my comment](#2183 (comment)) or discuss what the right way to move forward is particularly w/r/t how much we continue to generate for downstream BL apps: *i.e.*, if we don't give them a working SolrWrapper, do we generate/ship a working docker-compose configuration? Or do we get out of that business entirely? This is beyond the scope of this PR.

For this reason, perhaps the best place is somewhere on the [project wiki](https://github.com/projectblacklight/blacklight/wiki). Happy to take suggestions on this.

Note that this PR changes the `blacklight:server` rake task to use `docker-compose` for Solr but I was unable to see this working---with Ruby 2.6 and Rails 6, but other combinations will yield different results---because when Blacklight uses EngineCart to generate the test app, there's a problem with webpack(er). If you generate without the `--skip-webpack-install` flag being passed to the `rails new` command, the Rails webpack generator runs and fails because the dependency is not declared. If you skip webpack installation, Rails generates an app that still contains `webpacker` in its Gemfile, and it's a multi-step process to strip out webpack(er) and use Sprockets in its stead ([1](http://mitrev.net/ruby/2019/12/27/rails-6-without-webpack/), [2](https://www.reddit.com/r/rails/comments/b0goct/webpacker_for_non_js_people/eih2930/), [3](https://stackoverflow.com/a/58518795)). That said, I did not alter this behavior or attempt to fix the underlying problem since it is orthogonal to how we spin up Solr for CI/testing of Blacklight.

Fixes #2195
Fixes #2231
Closes #2256

In this way, we are using docker-compose for development and testing of the Blacklight gem itself, not for downstream purposes such as generation of new Blacklight applications, which will continue to use solr_wrapper.

This is currently a draft PR, intended to supersede #2256. This is not yet done, though, because...

It is not clear to me where information like this is currently documented. The README is short and sweet, and for this reason I suspect it is not a good place for such internal development documentation to live. Other options include `CONTRIBUTING.md`, but that is more focused on higher-level contribution process than particular technical steps.

Note, I also don't think the Quickstart is the right place, so this ticket has nothing to do with #2183, which I think we should either close as a `wontfix` per [my comment](#2183 (comment)) or discuss what the right way to move forward is particularly w/r/t how much we continue to generate for downstream BL apps: *i.e.*, if we don't give them a working SolrWrapper, do we generate/ship a working docker-compose configuration? Or do we get out of that business entirely? This is beyond the scope of this PR.

For this reason, perhaps the best place is somewhere on the [project wiki](https://github.com/projectblacklight/blacklight/wiki). Happy to take suggestions on this.

Note that this PR changes the `blacklight:server` rake task to use `docker-compose` for Solr but I was unable to see this working---with Ruby 2.6 and Rails 6, but other combinations will yield different results---because when Blacklight uses EngineCart to generate the test app, there's a problem with webpack(er). If you generate without the `--skip-webpack-install` flag being passed to the `rails new` command, the Rails webpack generator runs and fails because the dependency is not declared. If you skip webpack installation, Rails generates an app that still contains `webpacker` in its Gemfile, and it's a multi-step process to strip out webpack(er) and use Sprockets in its stead ([1](http://mitrev.net/ruby/2019/12/27/rails-6-without-webpack/), [2](https://www.reddit.com/r/rails/comments/b0goct/webpacker_for_non_js_people/eih2930/), [3](https://stackoverflow.com/a/58518795)). That said, I did not alter this behavior or attempt to fix the underlying problem since it is orthogonal to how we spin up Solr for CI/testing of Blacklight.

Fixes #2195
Fixes #2231
Closes #2256

In this way, we are using docker-compose for development and testing of the Blacklight gem itself, not for downstream purposes such as generation of new Blacklight applications, which will continue to use solr_wrapper.

This is currently a draft PR, intended to supersede #2256. This is not yet done, though, because...

It is not clear to me where information like this is currently documented. The README is short and sweet, and for this reason I suspect it is not a good place for such internal development documentation to live. Other options include `CONTRIBUTING.md`, but that is more focused on higher-level contribution process than particular technical steps.

Note, I also don't think the Quickstart is the right place, so this ticket has nothing to do with #2183, which I think we should either close as a `wontfix` per [my comment](#2183 (comment)) or discuss what the right way to move forward is particularly w/r/t how much we continue to generate for downstream BL apps: *i.e.*, if we don't give them a working SolrWrapper, do we generate/ship a working docker-compose configuration? Or do we get out of that business entirely? This is beyond the scope of this PR.

For this reason, perhaps the best place is somewhere on the [project wiki](https://github.com/projectblacklight/blacklight/wiki). Happy to take suggestions on this.

Note that this PR changes the `blacklight:server` rake task to use `docker-compose` for Solr but I was unable to see this working---with Ruby 2.6 and Rails 6, but other combinations will yield different results---because when Blacklight uses EngineCart to generate the test app, there's a problem with webpack(er). If you generate without the `--skip-webpack-install` flag being passed to the `rails new` command, the Rails webpack generator runs and fails because the dependency is not declared. If you skip webpack installation, Rails generates an app that still contains `webpacker` in its Gemfile, and it's a multi-step process to strip out webpack(er) and use Sprockets in its stead ([1](http://mitrev.net/ruby/2019/12/27/rails-6-without-webpack/), [2](https://www.reddit.com/r/rails/comments/b0goct/webpacker_for_non_js_people/eih2930/), [3](https://stackoverflow.com/a/58518795)). That said, I did not alter this behavior or attempt to fix the underlying problem since it is orthogonal to how we spin up Solr for CI/testing of Blacklight.