> -----Original Message----- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > Sent: Friday, May 07, 2004 3:54 PM > To: Jakarta Commons Developers List > Subject: Re: [beanutils] PROPOSAL: eliminate core dependency on > collections > > > IMHO Commons should not to foist jars on people that they don't ask for. > > Foisting is bad manners, is one key reason why commons gets > criticised, and > gives people a bad impression of both the base project (eg beanutils) and > the dependency (collections). For example, I have a bad impression of all > projects where [logging] is foisted on me, and thus a bad impression of > [logging].
Would you prefer that the components that are "foisting" logging on you did no logging? Or would you prefer that they each implemented their own version of Commons Logging instead? > (Note that a few years ago I argued for complex dependencies - > now I go with > the charter and argue for no dependecies if possible. This is one of the > hardest concepts to grasp in commons, and took me ages to get. > But it is key > if we are to remain successful.) > > > I'm in favour of these separations from a [collections] POV because many > projects have dependencies on collections.jar when they don't need to, > foisting [collections] on people when it shouldn't be, giving > collections a > bad name. The other side of this coin is that we effectively encourage people to not take advantage of all the useful stuff in Collections, and duplicate it or do their own thing, just to avoid the dependency. That is just wrong. > The KEY THING is for those projects that remove a dependency to not expose > any [collections] specific code in their API. This is where the hibernate > example shows that they went wrong, because they copied and exposed > NestableException - we must strive to avoid that, and fix it where we have > already failed. That's a reasonable goal. > The second, and separate, aspect is where a project like > beanutils has some > classes that definitely DO need the dependency. Having a separate > 'combination' jar, beanutils-collections in this case, works > well. Its clear > as to who owns and maintains the code, and clear as to a separate > dependency. > > > I understand the difficulty other committers have with this. Its not > 'normal' coding practice, and flies in the face of 'normal' code > reuse, but > it is the Right Thing to do. You forgot to add "in [your] opinion". Or perhaps you really did mean that you know what's right, and those of us who disagree with your POV are just not smart enough to understand? ;-) -- Martin Cooper > > Stephen > > ----- Original Message ----- > From: "Eric Pugh" <[EMAIL PROTECTED]> > > Well yes, if you just want BeanUtils, then having Collections > is a pain.. > > But typically if you are importing things like BeanUtils then you are > using > > other commons components, and you may very well end up having > Collections > > anyway. I know that in most of my projects I use BeanUtils and Lang and > > Collections because I know what they provide and find them useful. > > > > For Hibernate, they cloned the NestableException from Lang to remove the > > dependency. Great.. But I still have Lang. Now I keep throwing a > > net.hibernate..NestableException when I wanted a > > org.apache..lang.exceptions.NestableException due to code > completion in my > > IDE! > > > > Unless users are working in an environment where minimizing the total > number > > of jars is crucial, I don't think cloning a dependency is worth > it to save > a > > jar. > > > > Lastly, it seems like you end up removing a dependency on > Collections, and > > add a dependency on BeanCollections.. And now, as a user, I > have to make > a > > decision on whether to include BeanCollections or not.. Which means I > need > > to learn more about BeanUtils to make an intelligent decision, which > raises > > the bar to use. > > > > My 2 cents.. :-) > > > > Eric > > > > > -----Original Message----- > > > From: David Graham [mailto:[EMAIL PROTECTED] > > > Sent: Friday, May 07, 2004 2:03 PM > > > To: Jakarta Commons Developers List > > > Subject: RE: [beanutils] PROPOSAL: eliminate core dependency on > > > collections > > > > > > > > > > > > --- Martin Cooper <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: robert burrell donkin > > > > > [mailto:[EMAIL PROTECTED] > > > > > Sent: Thursday, May 06, 2004 12:15 PM > > > > > To: Jakarta Commons Developers List > > > > > Subject: [beanutils] PROPOSAL: eliminate core dependency on > > > > collections > > > > > > > > > > > > > > > PROPOSAL: eliminate the core dependency on commons-collections > > > > > > > > No doubt I'm sounding like a broken record and/or a lone > voice in the > > > > wilderness, but I really don't like the whole idea of > cloning classes > > > > from > > > > one Commons component into some other package to "eliminate a > > > > dependency". > > > > > > I agree with you that this is a complete hack and a generally bad idea > but > > > what seems to have been lost in the discussion is that this is a > > > *temporary* solution. The cloned classes will only exist for one > release > > > so the API can be deprecated. > > > > > > IMO, there is absolutely no reason for Digester, BeanUtils, Validator, > or > > > most other commons component to have a dependency on Collections. > > > Removing this dependency will benefit many projects that just want to > use > > > BeanUtils without dragging around a large and mostly unused > Collections > > > jar. > > > > > > David > > > > > > > > > > > Commons came into being so that people could *share* > implementations, > > > > and > > > > *avoid* cloning them. When classes are cloned, you no longer get the > > > > benefits of bug fixes coming from a common component, > advances in the > > > > design > > > > of common components, more eyes looking at the classes in > the context > of > > > > a > > > > component whose purpose is well-defined, etc. > > > > > > > > When a developer needs to add functionality to an ex-client of a > > > > component > > > > like Collections, they might clone another class. Before > long, people > > > > will > > > > lose track of how many cloned classes there are, and there > will be so > > > > many > > > > hidden potential dependencies that it would make a whole lot more > sense > > > > to > > > > depend on the original package, but it just won't occur to people to > do > > > > that > > > > any more. > > > > > > > > I'm not going to -1 this, because it seems clear that there > is support > > > > for > > > > it, but frankly I just don't understand the mentality that > says it's a > > > > good > > > > thing to *not* share components that were designed from the > get-go to > be > > > > shared. Bizarre. > > > > > > > > -- > > > > Martin Cooper > > > > > > > > > > > > > > > > > > rationale - this will not only eliminate a sizable dependency for > many > > > > > products depending on beanutils but also reduce chances of > > > > > compatibility issues with the various versions of collections. > > > > > > > > > > PLAN: > > > > > > > > > > 1 add org.apache.commons.collections.ArrayStack and > > > > > org.apache.commons.collections.Buffer source to beanutils > (these are > > > > > required by the public API) > > > > > > > > > > 2 replace the references to FastHashMap with a private static > > > > > implementation. consider whether to replace this altogether. > > > > > > > > > > 3 factor out a new bean-collections jar under > extras/bean-collections > > > > > containing the (cool) implementations of collections stuffs using > > > > > beanutils bean-magic. > > > > > > > > > > i've made a start on this work (so if anyone has any reasonable > > > > > objections, now would be a very good time to state them :) but i'd > be > > > > > willing to change if anyone comes up with any improvements to this > > > > > plan. > > > > > > > > > > - robert > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Win a $20,000 Career Makeover at Yahoo! HotJobs > > > http://hotjobs.sweepstakes.yahoo.com/careermakeover > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
