On Thu, Sep 12, 2019 at 5:24 PM Gilles Sadowski <gillese...@gmail.com> wrote:
> 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, Take a look at the PR, I added comments to allow the PR to have 0 deps. Gary > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
