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



---

Reply via email to