elharo commented on PR #490: URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1976603939
Yes, a good BOM is a workaround; but it's still only a workaround. and one that operates post facto. That is, first the developer sees their project break. Then they spend an hour to a day or more debugging it. How long it takes depends on how familiar they are with Maven dependency trees and whether they immediately recognize the symptoms. If you've encountered it before, you curse and say, "oh yeah, that again" and then start inspecting with mvn dependency:tree and google searches until you figure out exactly which exclusion or BOM you need to add where. If you haven't debugged one of these problems before, though, it's going to take a lot longer to figure it out. The kindest thing we can do for developers is to change package names and Maven coordinates at the same time, or not at all. As to an Apache-wide BOM that features coherent library versions, it's not a bad idea. A cross-functional team I was part of spent a couple of years creating [such a thing for the Google Cloud Platform](https://github.com/googleapis/java-cloud-bom). The amount of cat herding involved was significant. The majority of the effort was not in writing the BOM, but simply synchronizing the dozens of projects so that a consistent, compatible set of library versions existed and could be released at the same time. However, that was within one company that mostly belonged to a single product area. Apache is far more diverse and much less well funded. -- 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]
