Thanks, Jan for all the explanations and sorry for the off-topic intrusion on the other thread. All makes sense,
Cheers -------------------------- Alessandro Benedetti Apache Lucene/Solr PMC member and Committer Director, R&D Software Engineer, Search Consultant www.sease.io On Fri, 21 Jan 2022 at 14:28, David Smiley <dsmi...@apache.org> wrote: > Yeah +1 to increase modularization in general. If for some reason this > makes the functionality harder to use (which I sympathize with), I think we > should instead direct our energy to making modules/packages easier to use. > I'm thrilled about Jan's proposal to simply list the module names on > bin/solr at startup. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Jan 21, 2022 at 8:55 AM Jan Høydahl <jan....@cominvent.com> wrote: > >> There was a message from Alessandro in another thread >> <https://lists.apache.org/thread/q014rj1o4cnhq6olr3krnm66q44868x6>, >> which I'll answer here instead: >> (I'm posting the full question below my answers here for context) >> >> Many questions, and definitely a tangent :) But let me try a short answer >> >> What makes a module(contrib) a module(contrib)? >> >> >> Historically I think it actually was some new contribution that we wanted >> to be optional, perhaps since it was experimental, perhaps due to extra >> dependencies, don't know. >> I think the funny name "contrib" has fended us off from putting new >> tunctionality in modules, and instead committers have continued to add to >> solr-core all kinds of things. >> What I'm trying to push for with the dev-doc linked in the original mail >> is to shift our mindsets. >> You should have a really good reason for NOT putting some new >> functionality that is not going to be used by a majority of users, into a >> module. >> >> *From now on I'll use 'module' where I intend a package under contrib.* >> >> >> This is still in flux until >> https://issues.apache.org/jira/browse/SOLR-15917 lands on main. After >> that "contrib" will be history both in code and docs. >> >> I am referring to first-party modules such as ltr or langid. >> My initial understanding was that a module in contrib, is an integration >> with some external dependency (like langid with OpenNLP, Tika or >> langdetect). >> But then, why is *ltr* a module? It doesn't really integrate with any >> external dependency. >> >> >> Again, it's all historic reasons here. Bloomberg wisely contributed ltr >> and analysis as contrib modules. Kudos! >> >> Then, should this be fixed and brought inside the Solr core? >> >> >> Rather the opposite. We should lift much more non-core features out of >> core and into modules. That's why I wrote a scaffoldNewModule.py script >> to lower the bar for those wanting to do that. I'm lifting out >> JWTAuthPlugin in https://issues.apache.org/jira/browse/SOLR-15907 since >> it is not needed by all users >> >> And what about first party/third party modules? >> I don't think there's any visible difference right now, but in case we >> want to make a difference, should we create a sort of official "Solr Plugin >> Marketplace" ? >> >> >> A 1st party package will be (still not ready) a module that has a >> manifest added to it and that can be installed locally via pacakge manager. >> >> The pkg manager has a concept of package repos. So you can already today >> add a remote repo, see examples in the dev-doc. >> See also https://issues.apache.org/jira/browse/SOLR-14688 for a proposed >> 1st party package design. That JIRA is 1,5 years old :) >> The thougt is that the Solr project at some point release our modules as >> separate JAR files to the download repository, and publish >> a repository.json file at solr.apache.org/repository or similar. Then we >> can release a slim tgz with only solr-core, and users can pull >> down the packages they like. Perhaps we'll see some of this materialize >> in 9.x or at least in 10.0. Until then, all we have is >> contribs (soon to be named modules) :) >> >> Jan >> >> 21. jan. 2022 kl. 14:17 skrev Alessandro Benedetti <a.benede...@sease.io >> >: >> >> I would also add a tangential question (rather than answers at this >> point): >> What makes a module(contrib) a module(contrib)? >> *From now on I'll use 'module' where I intend a package under contrib.* >> >> I am referring to first-party modules such as ltr or langid. >> My initial understanding was that a module in contrib, is an integration >> with some external dependency (like langid with OpenNLP, Tika or >> langdetect). >> But then, why is *ltr* a module? It doesn't really integrate with any >> external dependency. >> It's additional query parsers and components for a key Solr functionality. >> Is it just a legacy consequence of the fact that initially, Bloomberg >> contributed the module? >> Maybe this applies to other modules as well (analytics?). >> Then, should this be fixed and brought inside the Solr core? >> >> And what about first party/third party modules? >> I don't think there's any visible difference right now, but in case we >> want to make a difference, should we create a sort of official "Solr Plugin >> Marketplace" ? >> (I proposed the idea to Lucidworks many years ago when I was working for >> a partner, and for a certain amount of time, I think there was a Solr >> Plugin Marketplace, but it was proprietary). >> >> I am curious to understand what you think about this and then reason >> about the naming convention. >> >> Cheers >> >> >> >> --- >> >
