Changing the subject to kick it more open. My view is:
(From earlier) "As a basic rule, I think it's pretty fair to state that package hierarchy should be obeyed as far as dependencies goes. This means that a package's classes may not depend on a sibling package, or a child package, but it may depend on a super-package or classes within the same package. " Siblings sometimes have to depend on each other, but it's the same type of dependency as inter-project dependencies. Allowing for a single class to be copy and pasted is too much though. I'd be interested in hearing counter-arguments to this viewpoint. Hen On Wed, 2 Jun 2004, Tim O'Brien wrote: > > -----Original Message----- > > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 01, 2004 5:24 PM > > To: Jakarta Commons Developers List > > Subject: Re: [lang] Re: cvs commit: > > jakarta-commons/lang/src/java/org/apache/commons/lang Validate.java > > > > > I'm confused -- why shouldn't a class in [lang] have > > dependencies to > > > other classes in [lang]? Isn't this taking things too far?? > > > > Its part of [lang] being broad and shallow. In effect, [lang] > > is a loose grouping of APIs in a similar vein. As such it > > should be easily broken into many parts. > > > > ie. a user should be able to come along and take one class (wherever > > possible) and paste it into their own CVS/project. > > > > Think of it as a single class jar file. [lang] just provides > > a home for it without needing the additional jar packaging. > > > > Stephen > > I can't say I agree with this POV, but I do think that it needs a more > formal fleshing out than a Re: thread for a CVS commit. > > I can see the benefit of reducing dependencies among different projects, but > I don't see a good rationale for not having Validate use StringUtils and/or > ArrayUtils. I'm not of the opinion that we should increase the effort of > maintaining common components because there are people who cut/paste code > into separate projects. > > Respectfully, > > Tim > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
