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].
(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 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. 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. 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]
