1. [Do we want a convention?] I'd be fine with a convention as long as we're willing to be flexible on it or evolve it as more modules come in. If we're expecting that 9.x will bring in other new modules but we don't know what those are, then we can't be too strict on any particular naming.
2. [should we rename the contribs/modules for 9.0 when we throw them around anyway?] Sure, +1 to the proposed names. Jason On Fri, Jan 21, 2022 at 1:53 PM Houston Putman <[email protected]> wrote: > I agree that standardizing the names would be nice. > > Another good option is to have a ref-guide page that lists all the > modules, explains their purpose and links to relevant documentation. > This page could be broken down by feature, much like your proposed names > would be. > > On Fri, Jan 21, 2022 at 1:47 PM David Smiley <[email protected]> wrote: > >> +1 I like your proposed names. Some of our names are so short now that >> only us know what they are at a glance. >> >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Fri, Jan 21, 2022 at 11:01 AM Jan Høydahl <[email protected]> >> wrote: >> >>> There is kind of a proposal in >>> https://github.com/apache/solr/blob/main/dev-docs/plugins-modules-packages.adoc#module-naming >>> already, but I'd like to discuss the general idea and what structure makes >>> the most sense here. With my "type" proposal, you can easily map the new >>> names for the various contribs, e.g. "backup-s3", "backup-gce", >>> "update-extraction", "update-langid", "search-analytics" etc. Other >>> structures are also probably possible? Or we could just leave it up to each >>> module author as before :) >>> >>> Jan >>> >>> 21. jan. 2022 kl. 15:25 skrev David Smiley <[email protected]>: >>> >>> Now is a great time to do some name changes. I suggest that you make a >>> specific proposal of what the names should be. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Fri, Jan 21, 2022 at 8:18 AM Alessandro Benedetti < >>> [email protected]> wrote: >>> >>>> 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 >>>> >>>> >>>> -------------------------- >>>> 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 10:47, Jan Høydahl <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> In >>>>> https://github.com/apache/solr/blob/main/dev-docs/plugins-modules-packages.adoc#module-naming >>>>> I suggested standardizing contrib/module names. We did not discuss it in >>>>> yesterday's committer meeting, and it may be a bit too much for 9.0. But >>>>> I'd like to discussed, since we are anyway renaming everything in >>>>> SOLR-15917 "contrib->module". >>>>> With as few contribs as we had so far it has not really been an issue. >>>>> But the reason I suggested it is because I anticipate a huge growth in >>>>> number of modules/packages during 9.x, and it can get messy. Another >>>>> reason >>>>> for having a convention is that it forces the module/package creator to >>>>> think through whether the proposed module has the right granularity. Take >>>>> for instance the new "HDFS" or "Hadoop" module. It won't fit into either >>>>> of >>>>> my proposed types, as it contains both a directoryFactory, one or two >>>>> authentication plugins and one backup repository. That of course suggests >>>>> that the module is too big and should be divided. Another reason is that >>>>> when we have 50 modules / packages it would be far better for users to be >>>>> able to find all backup repositories by looking for backup-* rather than >>>>> guess from naming what it is. Perhaps a bad example since both repo >>>>> contribs have a suffix "-repository" today. But then "-repository" is not >>>>> as user friendly as "backup-". >>>>> >>>>> So I guess I'd like your opinion on >>>>> >>>>> 1) Do we even want a convention (at least for our own code?) >>>>> 2) If yes, should we rename the contribs/modules for 9.0 when we throw >>>>> them around anyway? >>>>> 3) When we start adding package manifests to the modules, should there >>>>> be a 1:1 between module name and package name? >>>>> >>>>> Refarding the last point, we could apply such standardized naming >>>>> convention for the packages only and leave module names as-is, i.e. you'd >>>>> do "solr package install update-extraction" even if the module name >>>>> is "extraction". >>>>> >>>>> Jan >>>>> >>>> >>>
