commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Date Tue, 25 Jun 2002 23:47:44 GMT

I'm not sure I understand what's going on here:

- you don't need a proposal for a sandbox component

- Collections is in jakarta-commons and has been released - backward 
compatibility is a must ( for me - i.e. -1 on any change that is not 
backward compatible with collections-1.0 ). I would like to see very 
serious arguments for deprecating or refactoring - and estetics do not
qualify.

- what is the purpose of this ? Is there any project in jakarta that 
specifically need this ? I don't think the purpose of jakarta-commons
is to create random code that may be needed, but to host common components 
shared by different jakarta projects. 

There is already a jakarta project with the goal of creating patterns
( or something like that ), it may be better to do this 
development there. 

Please leave commons to stuff that is actually needed by projects 
( hopefully more than one ). 


Costin


On Tue, 25 Jun 2002, Stephen Colebourne wrote:

> Please find attached a proposal for a new sandbox component. This impacts
> both Collections and Util through refactoring.
> 
> Background:
> Discussions on the architecture of sandbox components have indicated that
> collecting together generic patterns such as factory, comparator and
> transformation code in one place would be useful. However, no current
> sandbox component is willing to take on the role.
> 
> Affects on Collections:
> The comparator package, Predicate, PredicateUtils (not the collections),
> Transform, Closure, SimpleObjectFactory and FactoryUtils classes would be
> copied to Pattern. Ideally, the classes will be deprecated for later removal
> **.
> 
> The principal issue for Collections is that Pattern will be a new component,
> untested and in the sandbox. The aim of Pattern must therefore be to proceed
> to a stable 1.0 commons release ASAP, and preferably before the next
> collections release.
> 
> The principal advantages for Collections are that it can focus on
> collections rather than on patterns, and that a wider range of Prdeicates,
> Transforms, Comparators and Factories will be available because they will
> have their own focus.
> 
> Affects on Util:
> The comparator classes currently in Util would be copied to Pattern.
> Ideally, the originals in Util would be removed. This should cause no issues
> as Util is a sandbox component.
> 
> My understanding is that I can start a sandbox component without a vote or
> discussion, but it seemed better to be clear on this occasion ;-)
> 
> Stephen
> 
> ** Changes dependent on Pattern reaching 1.0 before Collections' next
> release
> Predicate, Transform and Closure in Collections extend their replacements in
> Pattern and be deprecated in Collections.
> The comparators in collections are deprecated.
> PredicateUtils, SimpleObjectFactory, FactoryUtils and some Comparators
> haven't been released yet, so could be removed.
> 
> 
> 
> From: Nicola Ken
> > What you propose then are generic patterns, and I would assume that
> > Identifiable is part of them, since it's a common concern that crosses
> > aspects.
> >
> > I think that there is much more value in these than possible problems,
> > really *much* more, so you have my +1 for them.
> >
> > Which means I will help :-)
> 
> Nicola Ken, I've included you as an initial committer.
> 
> 


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


Mime
View raw message