You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by "Anton Gozhiy (Jira)" <ji...@apache.org> on 2019/12/04 15:54:00 UTC

[jira] [Created] (DRILL-7465) Revise the approach of handling dependencies with incompatible versions

Anton Gozhiy created DRILL-7465:
-----------------------------------

             Summary: Revise the approach of handling dependencies with incompatible versions
                 Key: DRILL-7465
                 URL: https://issues.apache.org/jira/browse/DRILL-7465
             Project: Apache Drill
          Issue Type: Task
            Reporter: Anton Gozhiy


In continuation of the conversation started [here|https://github.com/apache/drill/pull/1910].
Transitive dependencies with different versions is a common problem. The first and obvious solution would be to add them to Dependency Management in a pom.xml, and if backward compatibility is preserved it will work. But often there are changes in API, especially when major versions are different.

Current approaches used in Drill to handle this situation:
 * Using Maven Shade plugin
 ** Pros:
 *** Solves the problem, as libraries use their target dependency version.
 ** Cons:
 *** Requires a lot of changes in code and some tricky work bringing all component libraries together and relocating them.
 *** Will probably increase the jar size.
 * Patching conflicting classes with Javassist (Guava and Protobuf)
 ** Pros:
 *** Easier than shading to implement.
 *** Only one dependency version is used.
 ** Cons:
 *** This is a dark magic )
 *** It is hard to find all places that need a patch. This may cause some ugly exceptions when you least expect them.
 *** Often needs rework after the library version upgrade.
 *** For this to work, patching must happen in the first place. This can theoretically cause race conditions.
 *** Extending the previous paragraph, patching is need to be done before all tests so they all should be inherited from one with patching. This is obviously an overhead.

The idea of this task is to stop using patching at all due to it's cons and change it either to shading or some other approach if it exists.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)