Re: Dependency hell again

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Dependency hell again

Dawid Weiss-2
The problem with Solr dependencies is that they reflect ant state of
things (they are not transitive). So normally you'd just import
Zoookeeper and let it take care of upgrades to libraries it depends
on. This wouldn't be needed:

implementation ('org.xerial.snappy:snappy-java') { transitive = false
} // required for instantiating a Zookeeper server in tests

> Let me see if I'm on the right track. I'm working on upgrading Zookeeper to 3.6.1 and I'm caught in dependency hell again. That version of ZK relies on org.xerial.snappy:snappy-java=, which is distributed with it.
> The problem is that we instantiate a ZookeeperServer in solr/test-framework/src/java/org/apache/solr/cloud/ and it blows up with NoClassDef Snappy(OutputStream | InputStream).
> I included the snappy jar in versions.props and did all the magic about adding license and notice files etc. All ASL licensed so that's OK.

I'd need to see what you did. Is there an issue and a patch with this?

> Then adding the following line to solr/test-framework/build.gradle fixed running the tests:
> implementation ('org.xerial.snappy:snappy-java') { transitive = false } // required for instantiating a Zookeeper server in tests
> It doesn't seem to matter whether I put the above in the build.gradle files in solr or solrj or test-framework, but since the file that blows up is in test-framework that seems right?

I don't know. I'd have to see the code and analyze it.

> I still have to test whether we need something similar for running embedded ZK, but before I go there I thought I'd ask if there's anything obviously amiss with what I've done so far. Besides, it's late at night again… If it needs to be include other places, is it right to include it in multiple places? I’d guess that solr/core/build.gradle would be the other candidate but have to test it out.

The best way to resolve such questions would be to work on making Solr
dependencies transitive - this would limit their number (number of
"this depends on ..." clauses, not JARs) and add clarity on what
depends on what [1]



To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]