commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject RE: [beanutils] PROPOSAL: eliminate core dependency on collections
Date Fri, 07 May 2004 16:53:45 GMT

--- Gary Gregory <ggregory@seagullsw.com> wrote:
> I'm with Martin 100%. In addition, promoting the re-use of components
> would lead to /better/ project boundaries and organization, better
> slicing and dicing of jar files.

That's exactly what we're trying to do.  Removing the Collections
dependency from BeanUtils, Digester, and Validator helps reduce the
current dependency graph mess.  Remember that copying classes is only a
temporary solution until the deprecated API is removed.

David

> 
> Thank you,
> Gary 
> 
> > -----Original Message-----
> > From: Martin Cooper [mailto:martinc@apache.org]
> > Sent: Thursday, May 06, 2004 22:12
> > To: Jakarta Commons Developers List
> > Subject: RE: [beanutils] PROPOSAL: eliminate core dependency on
> > collections
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: robert burrell donkin
> > > [mailto:robertburrelldonkin@blueyonder.co.uk]
> > > 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".
> > 
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message