Le jeu. 12 sept. 2019 à 20:28, Gary Gregory <garydgreg...@gmail.com> a écrit : > > On Thu, Sep 12, 2019 at 11:42 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > Le jeu. 12 sept. 2019 à 17:32, Claude Warren <cla...@xenei.com> a écrit : > > > > > > The base code depended on commons-lang3 for building hashes. Is this > > > acceptable or should the hash generation code from lang3 be cut and > > pasted > > > into the classes. Not sure what the standard is in this project. > > > > There is no "standard". > > The least common denominator is "no dependency", not even towards > > other components of this "Commons" project (at the cost of duplication > > of code and/or API). > > > > Note that plenty of Commons components depend on other Commons components, > not just for testing. The most prominent example is Commons DBCP which > relies on Commons Pool; in which case duplicating code would be madness ;-)
Good to hear. > Some Commons components are "higher" level, like Commons Configuration and > Commons VFS, and so depend on other Commons components and other 3rd party > libraries. Right. But for those, it's their purpose to provide a uniform interface to external APIs. What I had in mind however is the kind of reluctance that popped up, for example, when [Text] introduced functionality related to random numbers but would not tolerate a dependency on the API defined in [RNG] (even though it was defined in a maven module to not incur any unnecessary dependencies). > It is fair to say that other components we have like Commons Lang and > perhaps Commons IO are considered "low" level and do not depend on > anything. I would expect Commons Lang to ever depend on anything else > (except for testing of course.) Sure, [Lang] should not depend on anything. But it also should not attempt to provide anything that would be better located in another component. Again, RNG functionality is a case in point. Creating [Text] was a step in the right direction (i.s. stop the bloat). We don't look actively into defining/refining scopes for the components, and how to make them modular. This should be a design requirement, rather than an afterthought. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
