How would its location in the repo address the problem? If we release something, we support that thing, and that means running tests. How do we run tests for a module that wants version X when Solr wants version Y? Docker and high level integration tests could be an answer but that would be a bunch of work. And I suspect if we look at the tests for it (I haven't) we'll see its testing details that may be impossible at an integration level.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Thu, Feb 23, 2023 at 2:44 AM Jan Høydahl <[email protected]> wrote: > 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] > >
