Hi. Le sam. 26 oct. 2024 à 01:51, Gary Gregory <garydgreg...@gmail.com> a écrit : > > Hello Gilles, > > Thank you for your thoughtful message. You raise some interesting points.
Thanks. I hope that you (and everyone reading this thread) noted that these points aim to settle (even if temporarily) issues (so that we can avoid endlessly bringing up the same arguments for every change of the same nature). > I've tried to address some and clarify others below. > > On Fri, Oct 25, 2024 at 8:46 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > Hi Gary. > > > > Le ven. 25 oct. 2024 à 13:48, Gary Gregory <garydgreg...@gmail.com> a > > écrit : > > > > > > >The recent flip-flopping changes in [CLI] and [Configuration] > > > > > > [CLI] has zero runtime dependencies. Are test dependencies an issue from > > > your POV? > > > > A few days ago, I think I saw another change which you questioned. > > > > I did not question the change, I vetoed the commits with a -1. I expect the > author to revert those changes. We know that I'm not a native English speaker, but: "To question [something]" is "to express doubt about [its] value" as per https://dictionary.cambridge.org So I referred to your wish (that the commit be reverted) by taking a step back and starting a discussion about _what_ justifies it (at a general level, as said at the beginning of this reply). > [...] > > > > > > > > > try to raise the question of when and how Commons components should > > > depend on other Commons components. > > > > > > Some components are low-level like Lang and IO, while others sit higher, > > > like VFS, Configuration, and Compress. > > > > Exactly, it is that hierarchy which I'd like to have consensus about, > > while, in practice, everyone here has its own. > > > Indeed ;-) > > In my view, Compress is a higher-level library since 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. Although you, I, and everyone else is entitled to having a "view", the main point is to reach consensus about a single one, in the context of this "Commons" (programming) project, because common rules will make it easier to manage and more robust (as you noted too). [In particular, you'd then be able to refer to a prospective "no copypasta" rule.] > > > > > > > > I think it is normal for higher-level components to reuse lower-level > > > building blocks, especially within our ecosystem. > > > > I agree, but it is a fact that any and all additions of a dependency > > to a (perceived) low-level component raised quite strong opposition. > > [A decade and some ago, the usual answer to such requests was: > > Do _not_ add; use the "shade" plugin instead.] > > > > I hope people stop giving that advice. I always tell people to never > shade, it makes it impossible to pick up a bug fix, much less a CVE fix. > Talk about making JAR files bigger! ;-) > > Look at the mess some tooling creates by shading in ASM: It's impossible to > use a new JDK until that JAR re-shades (I know, not a word) and releases a > new version. What a nightmare. I think it's the same with in-lining another > JAR's code. Both are anti-patterns in my book. I've always been a strong proponent of code reuse. But it was far from the top priority in "Commons" development, where it was very much trumped by the "no dependency" policy. [I personally welcome the change but I wonder when it came about...] If inter-component dependencies are now favoured (trends can change), it seems indispensable to agree on the "low" vs "high" level categories. My impression is that, via modularization, we could reach a hierarchy structure that would be satisfactory to most developers/maintainers. A position in the hierarchy will be tied to a "module", not a "component". > > > > > We also go > > > outside Commons as well, for example: Compress depends on many > > third-party > > > libraries to do its archiving and compression work: Zstd, Brotfi, and XZ. > > > > > > Lang has been justified since its inception as code low-level enough it > > > could have been in the JDK itself. > > > > Sure but, like several other components, it has grown a lot since its > > inception, and as Emmanuel points out (IIUC), it may have become > > too much of a bloat for the benefit of saving a few keystrokes (and, > > sometimes even not, if the JDK equivalent would be shorter). > > > > > I include Lang in my projects and > > > > Some developers do not. > > [That is not to say that it isn't useful to many of them.] > > > > > consider it part of the Java vocabulary. > > > > Strictly speaking it is not. > > > > I started that sentence with "I"; I'm making a statement about what I do > and think, not what anyone else does and thinks. I'm not trying to play with your words; I only split your sentence because the two aspects don't necessarily follow from each other. My point is, again: How do we reach consensus? [Because, in the particular examples that started this thread, what you do is obviously not compatible with what Emmanuel does.] > > > Also, I don't think that this consideration has any bearing on the > > subject of this thread, unless you advocate that all components > > should depend on [Lang] in preference over the JDK-equivalent > > functionality (?). [Obviously, many people would object to this.] > > > > Please see my previous comment; I'm not advocating that for Commons as a > rule. Wouldn't you agree that it would be better/safer/easier if we had some objective way to decide whether it is applicable to <this> component ("module", actually) but not to <that> one? > > > > On the one example I gave: Is it polemical to deprecate Commons > > functionality that has made its way into the JDK in favour of the > > latter? > > > > I think there is confusion here, this type of functionality is already > deprecated, for example, > org.apache.commons.lang3.ObjectUtils.equals(Object, Object) is deprecated. > I don't see a reference to a specific example in this thread. This thread advocates for a global discussion. A specific example was given by Emmanuel ("Base64") in the thread about vetoing his change(s). > > > > > > > Over the years, features have crept into Lang that we now have deprecated > > > and moved to Text. > > > > I know; I was there, and (IIRC) this (good IMO) move met some > > resistance. > > > > [FTR, my suggested move of modularizing Commons Math was > > met with fierce resistance by some, ending up in a fork (where > > the new codebase was actually... modularized).] > > > > FWIW, in the future, I'd like to see Compress split into modules so that > all dependencies can be non-optional, no surprises about missing JARs. +1 (for *all* components, including and particularly the larger ones like [Lang]). I started this move a long time ago with [Math] (the biggest of all "Commons" components, at the time). > > I hope the above is helpful, Sure, for a start. ;-) > thank you for reading through it all, I always do. Thank you for following up. I hope that others can join this discussion, and that we can converge to an actual plan. Regards, Gilles >>> [...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
