On Fri, Oct 25, 2024 at 7:25 PM Emmanuel Bourg <ebo...@apache.org> wrote:
> Le 25/10/2024 à 12:57, Gary Gregory a écrit : > > -1, please revert and stop inlining Commons methods all over itself. > Allow me to restate and elaborate on what I said in the Compress commit reply and in the thread titled "[All] Usage of (Commons) dependencies": No copypasta, please. I want to reduce code patterns that are duplicated all over the place. In my view, Compress is a higher-level library because it provides an SPI abstraction over archiving and compression using implementation through third-party libraries. Configuration is also a higher-level library that provides an SPI and different implementations, using third-party libraries like Spring. In both Compress and Configuration commits, pages and pages of diffs now duplicate code from other Commons JARs: This makes it impossible to benefit from bug fixes, performance improvements, and much less CVE fixes. This has many negative effects: Compress and Configuration are bigger, more complex, and harder to maintain. Furthermore, it increases the maintenance burden on Commons overall, if a maintainer fixes an issue in a low-level component (say Lang), should that maintainer hunt around Commons for copypasta? Should that maintainer pretend they don't know that copypasta exists? In the thread "[All] Usage of (Commons) dependencies", Gillies brings up an interesting tangent: Helping new contributors. One piece of advice I wouldn't want to give is: "Don't do what we do and copypasta code all over the place, instead think about how to best design and factor your code contributions, well expect here and there." I'd rather talk about something positive, and simpler ;-) HTH, Gary > > Could you elaborate why in this case please? Vetos to code changes have > to be technically justified. You can't just say that you don't like them. > > In this specific case, Commons Codec was used for the Base64 codec which > has now a standard equivalent in Java 8, and for the Hex class only used > in the PList implementations that will be replaced by the Java 17 > HexFormat class. Since Commons Configuration still supports Java 8 I > suggest using a trimmed down copy of the Commons Codec class to avoid > the extra dependency. > > Ironically, I authored the PList configurations 19 years ago, I hope I > can still have a say on how they are implemented today :) > > Emmanuel Bourg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
