> 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 <dsmi...@apache.org> 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 >
