steveloughran commented on pull request #2297: URL: https://github.com/apache/hadoop/pull/2297#issuecomment-700859880
Having checked up on those dependencies myself, yes, we are already shipping snappy-java 1.0.5 as a dependency of hadoop-common, by way of avro. Which makes a strong case for keeping the snappy codec in hadoop-common, declaring the snappy dependency as a compile time dependency, with the version we choose. This ensures hbase &c pick it up, and, because it is there: we aren't creating any more complications for people downstream than they get today. @saintstack happy with that? In which case, we actually go to the earlier patches, which just switch the codec to using the native one, and the pom changes to import it. Plus a release note 'you don't need native snappy no more'. We could stay with the current code, which is resilient to someone removing the JAR. Good: resilient bad: doesn't work so well if things (hadoop-client?) shade the snappy jar references. I don't know what to do there. Given the code is written, I'd go for "merge it as is and see what happens", but the "go back to the minimal binding" could well have lower maintenance costs down the line ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
