I'm not sure how many times this needs to be said but: Duplicating the classes is a *temorary* solution until the deprecated API is removed. BeanUtils won't be carrying duplicated Collections classes for long.
This issue has almost nothing to do with environments requiring limited jars; this is about responsible dependency management. The complaints about the state of commons project dependencies are valid and it's nice that we're finally dealing with them. David --- Eric Pugh <[EMAIL PROTECTED]> wrote: > 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] > __________________________________ 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]