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]
