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
