[
https://issues.apache.org/jira/browse/STORM-3593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053496#comment-17053496
]
Ethan Li commented on STORM-3593:
---------------------------------
This is awesome. Thanks for the analysis. We should fix them one by one if it's
not breaking backwards compatibilities.
> Inconsistent library versions notice.
> -------------------------------------
>
> Key: STORM-3593
> URL: https://issues.apache.org/jira/browse/STORM-3593
> Project: Apache Storm
> Issue Type: Improvement
> Reporter: Kaifeng Huang
> Priority: Major
> Attachments: apache storm.pdf
>
>
>
>
> Hi. I have implemented a tool to detect library version inconsistencies. Your
> project have 10 inconsistent libraries and 2 false consistent libraries.
>
> Take commons-io:commons-io for example, this library is declared as version
> 2.6 in storm-shaded-deps, 1.4 in external/storm-solr, 2.5 in
> storm-submit-tools 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
> commons-io:commons-io for example, if we harmonize all the library versions
> into 2.6. 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 2.6. Given that 9 APIs is used in module
> storm-server, 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|storm-server|9(15)|0(0)|0(0)|
> |2|integration-test|4(4)|0(0)|0(0)|
> |3|storm-submit-tools|1(1)|0(0)|1(1)|
> |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||
> |storm-submit-tools|storm-submit-tools/src/test/java/org/apache/storm/submit/dependency/DependencyResolverTest.java|modify|org.apache.commons.io.FileUtils.deleteQuietly(java.io.File)|
>
>
> As for false consistency, take org.apache.commons commons-lang3 jar for
> example. The library is declared in version 3.3 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)
