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. Sorry for the confusion if it was not in [CLI]... > > > 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. > > 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.] > 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. 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.] 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? > > 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).] > I am mindful of what belongs where. I didn't say otherwise. [You may remember that I also advocate(d) in order for a few things to be shuffled around to a more appropriate (IMHO) location...] However, there possibly are pathways that may satisfy everyone. Namely: Modularize any component that is composed of different functionalities and/or has grown "too large" (stricter definition TBD). Modularization has all sorts of benefits (security-wise, too) and is among the current "best practices". [As an aside, it is also a good "first project" for would-be contributors (because it does not require a deep understanding of the algorithms implemented, only of their interdependence, and at every point, it is easy to ensure that no functionality is lost).] Regards, Gilles > > HTH, > Gary > > On Fri, Oct 25, 2024 at 7:16 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > Hi. > > > > The recent flip-flopping changes in [CLI] and [Configuration] > > made me wonder if I should, again, try to raise the question > > of when and how Commons components should depend on > > other Commons components. > > > > Previous attempts (hinting at "when" and "how") have been > > ignored, but shouldn't we at least have a consensus, backed > > with a few hard rules? > > One such rule could be that if the minimum required JDK > > provides functionality that is also implemented in a Commons > > component, that component should > > 1. call the JDK equivalent functionality, > > 2. deprecate its (redundant) implementation > > in order to encourage developers to use the JDK instead, and > > allow us to trim down the Commons "bloat". > > > > WDYT? > > > > Regards, > > Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
