elharo commented on PR #490: URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1973447694
I believe @ppkarwasz is simply wrong. This change is not backwards compatible, and will break existing projects. It works in the very simple case where a project only has a direct dependency on commons-compress and has no transitive dependencies on commons-compress. However, in then much more common case where the dependency on commons-compress lives deep in the transitive dependencies this does not work. It's another instance of diamond dependencies and split packages. The basic problem is that a project can have the old commons-compress deep in the transitive dependency tree. One then updates some other library to a new version that now has common-compress-core deep in its transitive dependency tree. The classpath now contains both commons-compress and commons-compress-core, even though the developer of the project might never have heard of commons-compress. The project breaks in more or less clear ways, depending on Java version and the dependency graph, because a class is found in both commons-compress and commons-compress-core. See https://jlbp.dev/JLBP-5 and https://jlbp.dev/JLBP-6 -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
