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 <[email protected]> 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 <[email protected]>: > > 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 > > > > --- >
