Kaifeng Huang created ZEPPELIN-4658:
---------------------------------------

             Summary: Inconsistent library versions notice.
                 Key: ZEPPELIN-4658
                 URL: https://issues.apache.org/jira/browse/ZEPPELIN-4658
             Project: Zeppelin
          Issue Type: Improvement
            Reporter: Kaifeng Huang
         Attachments: apache zeppelin.pdf

Hi. I have implemented a tool to detect library version inconsistencies. Your 
project have 35 inconsistent libraries and 7 false consistent libraries.

Take org.apache.commons:commons-lang3 for example, this library is declared as 
version 3.3.2 in cassandra, 3.7 in zeppelin-integration, 3.4 in markdown and 
etc... Such version inconsistencies may cause unnecessary maintenance effort in 
the long run. For example, if two modules become inter-dependent, library 
version conflict may happen. It has already become a common issue and hinders 
development progress. Thus a version harmonization is necessary.

Provided we applied a version harmonization, I calculated the cost it may have 
to harmonize to all upper versions including an up-to-date one. The cost refers 
to POM config changes and API invocation changes. Take 
org.apache.commons:commons-lang3 for example, if we harmonize all the library 
versions into 3.9. The concern is, how much should the project code adapt to 
the newer library version. We list an effort table to quantify the 
harmonization cost.

The effort table is listed below. It shows the overall harmonization effort by 
modules. The columns represents the number of library APIs and API 
calls(NA,NAC), deleted APIs and API calls(NDA,NDAC) as well as modified API and 
API calls(NMA,NMAC). Modified APIs refers to those APIs whose call graph is not 
the same as previous version. Take the first row for example, if upgrading the 
library into version 3.9. Given that 9 APIs is used in module zeppelin-zengine, 
0 of them is deleted in a recommended version(which will throw a 
NoMethodFoundError unless re-compiling the project), 0 of them is regarded as 
modified which could break the former API contract.

||Index||Module||NA(NAC)||NDA(NDAC)||NMA(NMAC)||
|1|zeppelin-zengine|9(22)|0(0)|0(0)|
|2|zeppelin-integration|3(4)|0(0)|3(4)|
|3|jdbc|3(3)|0(0)|0(0)|
|4|..|..|..|..|


Also we provided another table to show the potential files that may be affected 
due to library API change, which could help to spot the concerned API usage and 
rerun the test cases. The table is listed below.



||Module||File||Type||API||
|zeppelin-integration|zeppelin-integration/src/test/java/org/apache/zeppelin/WebDriverManager.java|modify|org.apache.commons.lang3.SystemUtils.IS_OS_WINDOWS|
|zeppelin-integration|zeppelin-integration/src/test/java/org/apache/zeppelin/WebDriverManager.java|modify|org.apache.commons.lang3.SystemUtils.IS_OS_MAC_OSX|
|zeppelin-integration|zeppelin-integration/src/test/java/org/apache/zeppelin/WebDriverManager.java|modify|org.apache.commons.lang3.SystemUtils.IS_OS_LINUX|


 

As for false consistency, take org.apache.httpcomponents httpclient jar for 
example. The library is declared in version 4.5.1 in all modules. However they 
are declared differently. As components are developed in parallel, if one 
single library version is updated, which could become inconsistent as mentioned 
above, may cause above-mentioned inconsistency issues


If you are interested, you can have a more complete and detailed report in the 
attached PDF file.



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

Reply via email to