> separate repo can be used to test against many Solr versions. Imagine a > component that works across Solr versions 6x through 9x from day one. I can't > imagine such a component being part of the lucene-solr repo itself.
It'll be great to test contrib's on multiple Solr versions, but I can't see any blockers for this that are same-repo specific. Can you elaborate on what makes this tricky in a same-repo setup? AFAICT you can set up multiple gradle test tasks that rely on different solr-test-framework versions and run tests that way - regardless of where the code lives. (Or alternatively, docker images for various Solr versions as David suggested.) I think Jan's got a good point about how do-able it'll be in practice to have plugins support multiple major release versions. That said though, a lot of these questions (docker tests vs otherwise, cross major-version plugins?) will likely sort themselves out when it comes time to implement. On Tue, Feb 16, 2021 at 12:21 AM David Smiley <dsmi...@apache.org> wrote: > > I think embracing Docker is how we can identify if a plugin works in multiple > versions of Solr. The setup of such a test would start Solr via Docker and > install the plugin into a Solr server using the package manager. The test > code itself would interact with Solr purely via SolrClient. This would be an > integration / smoke level test for the plugin. I test my plugins at work > similar to this way at a "smoke" level, which follows "integration". What's > cool is that we can take the very same test and either have it run via an > embedded Solr (which we call an integration test) or a remote'ed Solr (run > via Docker, which we call our "smoke" test). Naturally, if a test makes > assumptions that only work in embedded, then it won't run in smoke mode, so > we have annotations to categorize the tests. I'd like to work on some JUnit > "Rule" for Solr, similar to what I have at work (and have done in the past) > -- https://issues.apache.org/jira/browse/SOLR-11872 > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Mon, Feb 15, 2021 at 9:17 AM Ishan Chattopadhyaya > <ichattopadhy...@gmail.com> wrote: >> >> Hoss, >> One important reason why separate repo for solr-extras is a good idea, as >> opposed to conrib modules, is that separate repo can be used to test against >> many Solr versions. Imagine a component that works across Solr versions 6x >> through 9x from day one. I can't imagine such a component being part of the >> lucene-solr repo itself. >> >> Also, today, contrib modules are shipped with Solr, which we don't want for >> new things we might want to build. >> >> On Mon, Jan 25, 2021 at 4:25 PM Ishan Chattopadhyaya >> <ichattopadhy...@gmail.com> wrote: >>> >>> I haven't been able to follow up on creation of the extras repo, but more >>> importantly I wanted to respond to Hoss. I'm out on an emergency for a week >>> or so, shall resume then. If there's a decision on this until then, I shall >>> accept it. >>> >>> On Mon, 25 Jan, 2021, 9:04 am Jason Gerlowski, <gerlowsk...@gmail.com> >>> wrote: >>>> >>>> Tentative +1 to Hoss' questions. I agree with his summary of the >>>> potential risks here, and I share his ignorance of the perceived >>>> benefits. >>>> >>>> (I thought for a time that this was driven by interest in having >>>> release cadences independent from Solr-core releases. I'm all for >>>> that goal, but if that's the motivation I'm not sure what the obstacle >>>> is to doing that with a single repo - all build systems these days >>>> support versioning and releasing modules independent of one another. >>>> But maybe that was never a driving factor here.) >>>> >>>> I know there have been a lot of discussions about this, and I know the >>>> repo has already been created. So maybe it's too late to object even >>>> if I wanted to, which I'm not sure I do. But can someone that >>>> understands the motivation please summarize what multiple-repos gets >>>> us over a single repo that outweighs the "cons" that Hoss mentioned? >>>> >>>> Jason >>>> >>>> On Thu, Jan 14, 2021 at 12:34 PM Chris Hostetter >>>> <hossman_luc...@fucit.org> wrote: >>>> > >>>> > >>>> > : As we discussed over the last few months, there seems a need to move >>>> > : non-core pieces away from the Solr core module. The contribs are >>>> > presently >>>> > : a good place, but it makes sense to have a separate git repository >>>> > hosting >>>> > : such modules. Some candidates that come to mind are the present day >>>> > contrib >>>> > >>>> > can you explain why it makes sense to have a separate git repo for these >>>> > things? >>>> > >>>> > I can think of lots of reasons why it makes sense to have a single >>>> > repo for all things solr (unified CI that quickly identifies if core >>>> > changes break "first order" plugins, shared feature branches & monotomic >>>> > commits of code that affects APIs and impls of those APIs, etc...) but >>>> > I've yet to see any concrete specifics of why multiple git repos are >>>> > "better" then just having distinct sub-projects (with distinct artifacts) >>>> > in the same repo other then "it makes sense" >>>> > >>>> > why does it make sense? >>>> > >>>> > why can't the ideas of "solr-sandbox" and "solr-extras" just be >>>> > directories in the "solr repo" ? ... what value is gained by making them >>>> > new repos? >>>> > >>>> > >>>> > -Hoss >>>> > http://www.lucidworks.com/ >>>> > >>>> > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>>> > >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
