Kaifeng Huang created SHIRO-746:
-----------------------------------
Summary: Inconsistent library versions notice.
Key: SHIRO-746
URL: https://issues.apache.org/jira/browse/SHIRO-746
Project: Shiro
Issue Type: Improvement
Reporter: Kaifeng Huang
Attachments: apache shiro.pdf
Hi. I have implemented a tool to detect library version inconsistencies. Your
project have 1 inconsistent library.
Take com.google.inject.extensions:guice-servlet for example, this library is
declared as version 4.2.2 in integration-tests/guice4, 3.0 in
integration-tests/guice3 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
com.google.inject.extensions:guice-servlet for example, if we harmonize all the
library versions into 4.2.2. 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 shows the overall harmonization cost on APIs. It seems your
project have no API invokes on this library, which could be safely upgrade to
4.2.2
||Index||Module||NA(NAC)||NDA(NDAC)||NMA(NMAC)||
|1|integration-tests/guice4|0(0)|0(0)|0(0)|
|2|integration-tests/guice3|0(0)|0(0)|0(0)|
|3|samples/guice|0(0)|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.
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)
