Is there a chance the module could be moved up a level in git, next to solr-exporter, with own build and a package manifest? We could still ship it in tarball as a 1st party package and document the bin/solr package install command necessary to install it.
I’d vote for a move in 10.0, with deprecation of the module-version in 9.x. Jan Høydahl > 23. feb. 2023 kl. 03:41 skrev David Smiley <[email protected]>: > > I suppose all code can wait till some future big version unless it's some > sort of bug fix applicable to the present. It's just a shame that a module > I perceive to be less used, delaying things. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Sun, Feb 19, 2023 at 11:08 PM Ishan Chattopadhyaya < > [email protected]> wrote: > >>> (e.g. by shading) it but it hasn't happened yet. Personally, I don't >> think >>> Hadoop-Auth is important enough to continue to thwart this progress on >>> SolrCloud. Agreed? >> >> Agreed, in principle. But, if your suggestion is that we do this in 9x, >> then I need more clarification as to why this can't wait until 10x. >> >> On Mon, Feb 20, 2023 at 9:35 AM Ishan Chattopadhyaya < >> [email protected]> wrote: >> >>>> We could stop shipping this module with 9.3, say, until the versioning >>> issue allows it to return. >>> >>> Not sure if I follow correctly, but do you mean we stop shipping >>> hadoop-auth with Solr starting 9.3? >>> >>>> On Mon, Feb 20, 2023 at 7:37 AM David Smiley <[email protected]> wrote: >>> >>>> FYI there's the beginning of an important conversation in >>>> https://issues.apache.org/jira/browse/SOLR-16116 pertaining to how we >>>> deal >>>> with modules that want version-X of a dependency but Solr-core would >> like >>>> to have version-Y. Let's further that discussion here. >>>> >>>> With a minor ClassLoader change, we could easily support this for a user >>>> with their own custom module, but these first-party modules are another >>>> matter. These are compiled, tested, and packaged by our build. It's >>>> probably too much work for our build to handle varying versions of a >>>> dependency? >>>> >>>> The problem has blocked progress on a strategic direction of SolrCloud >> for >>>> a year now, and the module in question is hadoop-auth, and the >> dependency >>>> is Curator. It's expected to be resolved by the Hadoop project someday >>>> (e.g. by shading) it but it hasn't happened yet. Personally, I don't >>>> think >>>> Hadoop-Auth is important enough to continue to thwart this progress on >>>> SolrCloud. Agreed? >>>> >>>> We could stop shipping this module with 9.3, say, until the versioning >>>> issue allows it to return. One way I prefer is to merely deactivate the >>>> Gradle module (or say, only tests & JAR publishing) thereby leaving >> source >>>> in-place, which is nicer for source control history when it returns, >> which >>>> we expect it to. Of course the other way is outright removal. >>>> >>>> ~ David Smiley >>>> Apache Lucene/Solr Search Developer >>>> http://www.linkedin.com/in/davidwsmiley >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
