You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ola Berg <ol...@arkitema.se> on 2002/06/24 00:36:44 UTC
Core architecture [was: Commons architecture]
Dimitri writes:
>I agree that one project is much better than many disparate ones. �However,
>I would like to suggest that rather than trying to combine many SOLUTIONS
>into one project, we collect REQUIREMENTS from all those projects currently
>doing the util stuff and try to address them all.
Yes. In the reflect thread I suggested the humble and servile approach: developers of the Core packages tries to fulfill the upper level guys\' needs so that they eventually will see that the Core packages are something to rely on.
I think it is about mentality: if Core developers has the attitude that they (we) are the humble servants of our presumptive end-users (other projects), and that the switch to use core packages is at the end-users\' discretion; then everything will follow.
We have to take a bird\'s view on their code: what problems are general, what are /TomCat/Ant/Whatever-specific, how did they solve it, how did they solve it etc. This attitude of the Core developers should prevail even when the Core developer and the end-user is the same person. \"When you code TomCat you serve TomCat, when you code Core you serve all\".
The standing argument against this is that it probably will involve some reengineering of work already done. My standing answer is that: 1) yes, if we are unlucky this will happen, 2) it is our firm belief that the benefits of single methods and patterns for low level mechanisms even at the binary level will eventually be greater than the costs, 3) the costs are ours and not yours, you switch to Core if and when it feels OK.
Jon writes:
>IMO one important consideration is that some of the core classes will
>likely depend classes in other core packages.
<snip/>
>I\'m guessing that this will be easier to do if
there is one subproject as Ola suggests.
Exactly. Or as Stephen suggested, I was just saying it again, without using the word \"madness\" ;-)
My first question deals with the scope of Core. And when I speak about scope, I am not referring to packages but to mechanisms, what mechanisms should Core support (division into packages could be a later issue).
A list with a few examples:
transformation - general interface for object transformation
type conversion - special application of transformation
conversion from and to String - special and useful application of type conversion.
object instantiation - factories and other patterns for instantiation. This is actually related to transformation.
pooling - supports different pools and pooling policies. This is dependent on instantiation patterns.
config - the pattern \"Object recieves config data\" is already present in Avalon. My idea of \"Configurator configures objects out of config data and keeps track of state, persistance and updates\" (related to pooling and factories and type conversion) is not present anywhere else than in my nu.viggo.* classes from what I have seen.
assertions - related to all issues of type safety in all packages, esp type safe collections in Commons Collection.
younameit - (Jon, tell us about your ideas, chances are that we have been thinking along the same lines)
Some of these might actually be better off in a separate project (so that the scope doesn\'t grow to much), but one can easily see that there are some common interfaces that some classes need to implement in order to acheive this inter-operability between packages. I support the idea of collecting the really general interfaces (Identifiable, Resetable etc) in a package of its own.
/O
--------------------
ola.berg@arkitema.se
0733 - 99 99 17
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I will create the sandbox package tonight, and begin committing code.
I will exclude comparators for the moment.
Stephen
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, June 26, 2002 8:33 AM
Subject: Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was:
Re: Core architecture [was: Commons architecture]]
> Stephen, just commit it and let's start workin on it.
> No vote is necessary now, and also no deprecation.
>
> Let's just give it a shot, move there stiff that has not yet been
> released (ie pure sandbox).
>
> If/when it's done, we'll see if there is really value in it.
>
> Discussions get forgotten, just code remains...
>
>
> 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.
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > <html>
> > <head>
> > <title>Proposal for Pattern Package</title>
> > </head>
> > <body bgcolor="white">
> >
> > <div align="center">
> > <h1>Proposal for <em>Pattern</em> Package</h1>
> > </div>
> >
> > <h3>(0) Rationale</h3>
> >
> > <p>The standard Java libraries provides for some very common design
> > patterns - Comparator/Comparable, EventListener, Observer/Observable,
Cloneable and Runnable
> > However, other generic pattern concepts are not supported. The
<em>Pattern</em>
> > Package provides these extra pattern interfaces. It also provides
reference
> > implementations and utilities for the additional interfaces and those
interfaces in Java.</p>
> >
> >
> > <h3>(1) Scope of the Package</h3>
> >
> > <p>This proposal is to create a package to support low level pattern
interfaces.
> > To be included an interface must be simple, have wide potential
applicability,
> > and not require a framework.</p>
> >
> > <p>This package also includes utility/reference implementation classes
for the pattern
> > interfaces and those pattern classes in java.lang and java.util.</p>
> >
> >
> > <h3>(1.5) Interaction With Other Packages</h3>
> >
> > <p><em>Pattern</em> relies only on standard JDK 1.2 (or later) APIs for
> > production deployment. It utilizes the JUnit unit testing framework for
> > developing and executing unit tests, but this is of interest only to
> > developers of the component. Patterns will be a dependency for
> > several existing components in the open source world.</p>
> >
> > <p>No external configuration files are utilized.</p>
> >
> >
> > <h3>(2) Initial Source of the Package</h3>
> >
> > <p>Some initial classes came from the Commons.Collections and
Commons.Util subprojects.</p>
> >
> > <p>The proposed package names for the new component are
> > <code>org.apache.commons.pattern.xxx</code> where xxx is the pattern
interface name,
> > such as <code>org.apache.commons.pattern.comparator</code>.</p>
> >
> >
> > <h3>(3) Required Jakarta-Commons Resources</h3>
> >
> > <ul>
> > <li>CVS Repository - New directory <code>pattern</code> in the
> > <code>jakarta-commons</code> CVS repository.</li>
> > <li>Mailing List - Discussions will take place on the general
> > <em>commons-dev@jakarta.apache.org</em> mailing list. To help
> > list subscribers identify messages of interest, it is suggested that
> > the message subject of messages about this component be prefixed
with
> > [Patterns].</li>
> > <li>Bugzilla - New component "Pattern" under the "Commons" product
> > category, with appropriate version identifiers as needed.</li>
> > <li>Jyve FAQ - New category "commons-pattern" (when available).</li>
> > </ul>
> >
> >
> > <h3>(4) Initial Committers</h3>
> >
> > <p>The initial committers on the Lang component shall be as follows:
> > <ul>
> > <li>Stephen Colebourne (scolebourne)</li>
> > <li>Nicola Ken Barozzi (nicolaken)</li>
> > <!-- Add your real name and user name here -->
> > </ul>
> > </p>
> >
> > </body>
> > </html>
> >
>
>
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was:
Re: Core architecture [was: Commons architecture]]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen, just commit it and let's start workin on it.
No vote is necessary now, and also no deprecation.
Let's just give it a shot, move there stiff that has not yet been
released (ie pure sandbox).
If/when it's done, we'll see if there is really value in it.
Discussions get forgotten, just code remains...
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.
>
>
>
> ------------------------------------------------------------------------
>
> <html>
> <head>
> <title>Proposal for Pattern Package</title>
> </head>
> <body bgcolor="white">
>
> <div align="center">
> <h1>Proposal for <em>Pattern</em> Package</h1>
> </div>
>
> <h3>(0) Rationale</h3>
>
> <p>The standard Java libraries provides for some very common design
> patterns - Comparator/Comparable, EventListener, Observer/Observable, Cloneable and Runnable
> However, other generic pattern concepts are not supported. The <em>Pattern</em>
> Package provides these extra pattern interfaces. It also provides reference
> implementations and utilities for the additional interfaces and those interfaces in Java.</p>
>
>
> <h3>(1) Scope of the Package</h3>
>
> <p>This proposal is to create a package to support low level pattern interfaces.
> To be included an interface must be simple, have wide potential applicability,
> and not require a framework.</p>
>
> <p>This package also includes utility/reference implementation classes for the pattern
> interfaces and those pattern classes in java.lang and java.util.</p>
>
>
> <h3>(1.5) Interaction With Other Packages</h3>
>
> <p><em>Pattern</em> relies only on standard JDK 1.2 (or later) APIs for
> production deployment. It utilizes the JUnit unit testing framework for
> developing and executing unit tests, but this is of interest only to
> developers of the component. Patterns will be a dependency for
> several existing components in the open source world.</p>
>
> <p>No external configuration files are utilized.</p>
>
>
> <h3>(2) Initial Source of the Package</h3>
>
> <p>Some initial classes came from the Commons.Collections and Commons.Util subprojects.</p>
>
> <p>The proposed package names for the new component are
> <code>org.apache.commons.pattern.xxx</code> where xxx is the pattern interface name,
> such as <code>org.apache.commons.pattern.comparator</code>.</p>
>
>
> <h3>(3) Required Jakarta-Commons Resources</h3>
>
> <ul>
> <li>CVS Repository - New directory <code>pattern</code> in the
> <code>jakarta-commons</code> CVS repository.</li>
> <li>Mailing List - Discussions will take place on the general
> <em>commons-dev@jakarta.apache.org</em> mailing list. To help
> list subscribers identify messages of interest, it is suggested that
> the message subject of messages about this component be prefixed with
> [Patterns].</li>
> <li>Bugzilla - New component "Pattern" under the "Commons" product
> category, with appropriate version identifiers as needed.</li>
> <li>Jyve FAQ - New category "commons-pattern" (when available).</li>
> </ul>
>
>
> <h3>(4) Initial Committers</h3>
>
> <p>The initial committers on the Lang component shall be as follows:
> <ul>
> <li>Stephen Colebourne (scolebourne)</li>
> <li>Nicola Ken Barozzi (nicolaken)</li>
> <!-- Add your real name and user name here -->
> </ul>
> </p>
>
> </body>
> </html>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Posted by robert burrell donkin <ro...@mac.com>.
+0
sounds like a good plan (but i don't have the time to actively support
your efforts right now).
BTW a word to the wise - prefixing [PROPOSAL] to your proposal is usually
a good idea
- robert
On Tuesday, June 25, 2002, at 10:34 PM, 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Posted by Morgan Delagrange <md...@yahoo.com>.
--- costinm@covalent.net wrote:
>
>
<snip/>
>
> - 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.
>
Well, technically backward compatibility to
collections-2.0. But otherwise yes, I also think both
deprecation and refactoring is best done when
required, not when desired.
<snip/>
>
> Costin
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was:
Re: Core architecture [was: Commons architecture]]
Posted by co...@covalent.net.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was:
Re: Core architecture [was: Commons architecture]]
Posted by Henri Yandell <ba...@generationjava.com>.
Remove the comparators in Utils from Utils. They were declined as a
submission to Collections due to being too specific and not generic
enough. In which case, they probably have no place in Utils.
That gets the generic comparators in Commons in one place.
Hen
On Wed, 26 Jun 2002, James Strachan wrote:
> -1
>
> I agree with Morgan. Can't we just leave the Comparators in Collections and
> make Utils dependent on Collections?
>
> James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util]
[was: Re: Core architecture [was: Commons architecture]]
Posted by Juozas Baliuka <ba...@mwm.lt>.
Utils can use Comparator interface for something like
"Utils.bubleSort(array,comparator)"
and user can use implementation from any project or implement it himself.
I don't think Collections or Utils needs to play with trivial "Callback"
interface implementation
if it is not used for some internal functionality .
At 11:40 2002.06.26 +0100, you wrote:
>-1
>
>I agree with Morgan. Can't we just leave the Comparators in Collections and
>make Utils dependent on Collections?
>
>James
>----- Original Message -----
>From: "Morgan Delagrange" <md...@yahoo.com>
>To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
><ni...@apache.org>
>Sent: Tuesday, June 25, 2002 10:46 PM
>Subject: Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was:
>Re: Core architecture [was: Commons architecture]]
>
>
> > -1 on moving the comparators package out of
> > Collections. It clearly falls in that domain; that's
> > where users would expect to find them. Also, all of
> > those comparators are released classes.
> >
> > Actually I'm suspicious of a "pattern" package. It
> > seems way, way too broad:
> >
> > "The standard Java libraries provides for
> > some very common design patterns -
> > Comparator/Comparable, EventListener,
> > Observer/Observable, Cloneable and Runnable
> > However, other generic pattern concepts are
> > not supported. The <em>Pattern</em>
> > Package provides these extra pattern
> > interfaces. It also provides reference
> > implementations and utilities for the
> > additional interfaces and those
> > interfaces in Java."
> >
> > "[G]eneric pattern concepts" sounds like a recipe for
> > hodge-podge. If you want to try out patterns, which
> > could be interesting, you definitely want smaller more
> > focused packages (e.g. a package devoted to XML
> > patterns).
> >
> > - Morgan
> >
> > --- Stephen Colebourne <sc...@btopenworld.com>
> > 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.
> > >
> > > > <html>
> > > <head>
> > > <title>Proposal for Pattern Package</title>
> > > </head>
> > > <body bgcolor="white">
> > >
> > > <div align="center">
> > > <h1>Proposal for <em>Pattern</em> Package</h1>
> > > </div>
> > >
> > > <h3>(0) Rationale</h3>
> > >
> > > <p>The standard Java libraries provides for some
> > > very common design
> > > patterns - Comparator/Comparable, EventListener,
> > > Observer/Observable, Cloneable and Runnable
> > > However, other generic pattern concepts are not
> > > supported. The <em>Pattern</em>
> > > Package provides these extra pattern interfaces. It
> > > also provides reference
> > > implementations and utilities for the additional
> > > interfaces and those interfaces in Java.</p>
> > >
> > >
> > > <h3>(1) Scope of the Package</h3>
> > >
> > > <p>This proposal is to create a package to support
> > > low level pattern interfaces.
> > > To be included an interface must be simple, have
> > > wide potential applicability,
> > > and not require a framework.</p>
> > >
> > > <p>This package also includes utility/reference
> > > implementation classes for the pattern
> > > interfaces and those pattern classes in java.lang
> > > and java.util.</p>
> > >
> > >
> > > <h3>(1.5) Interaction With Other Packages</h3>
> > >
> > > <p><em>Pattern</em> relies only on standard JDK 1.2
> > > (or later) APIs for
> > > production deployment. It utilizes the JUnit unit
> > > testing framework for
> > > developing and executing unit tests, but this is of
> > > interest only to
> > > developers of the component. Patterns will be a
> > > dependency for
> > > several existing components in the open source
> > > world.</p>
> > >
> > > <p>No external configuration files are utilized.</p>
> > >
> > >
> > > <h3>(2) Initial Source of the Package</h3>
> > >
> > > <p>Some initial classes came from the
> > > Commons.Collections and Commons.Util
> > > subprojects.</p>
> > >
> > > <p>The proposed package names for the new component
> > > are
> > > <code>org.apache.commons.pattern.xxx</code> where
> > > xxx is the pattern interface name,
> > > such as
> > >
> > <code>org.apache.commons.pattern.comparator</code>.</p>
> > >
> > >
> > > <h3>(3) Required Jakarta-Commons Resources</h3>
> > >
> > > <ul>
> > > <li>CVS Repository - New directory
> > > <code>pattern</code> in the
> > > <code>jakarta-commons</code> CVS
> > > repository.</li>
> > > <li>Mailing List - Discussions will take place on
> > > the general
> > > <em>commons-dev@jakarta.apache.org</em> mailing
> > > list. To help
> > > list subscribers identify messages of interest,
> > > it is suggested that
> > > the message subject of messages about this
> > > component be prefixed with
> > > [Patterns].</li>
> > > <li>Bugzilla - New component "Pattern" under the
> > > "Commons" product
> > > category, with appropriate version identifiers
> > > as needed.</li>
> > > <li>Jyve FAQ - New category "commons-pattern" (when
> > > available).</li>
> > > </ul>
> > >
> > >
> > > <h3>(4) Initial Committers</h3>
> > >
> > > <p>The initial committers on the Lang component
> > > shall be as follows:
> > > <ul>
> > > <li>Stephen Colebourne (scolebourne)</li>
> > > <li>Nicola Ken Barozzi (nicolaken)</li>
> > > <!-- Add your real name and user name here -->
> > > </ul>
> > > </p>
> > >
> > > </body>
> > > </html>
> > >
> > > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > =====
> > Morgan Delagrange
> > http://jakarta.apache.org/taglibs
> > http://jakarta.apache.org/commons
> > http://axion.tigris.org
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
> > For additional commands, e-mail:
><ma...@jakarta.apache.org>
> >
>
>
>_________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Posted by James Strachan <ja...@yahoo.co.uk>.
-1
I agree with Morgan. Can't we just leave the Comparators in Collections and
make Utils dependent on Collections?
James
----- Original Message -----
From: "Morgan Delagrange" <md...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<ni...@apache.org>
Sent: Tuesday, June 25, 2002 10:46 PM
Subject: Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was:
Re: Core architecture [was: Commons architecture]]
> -1 on moving the comparators package out of
> Collections. It clearly falls in that domain; that's
> where users would expect to find them. Also, all of
> those comparators are released classes.
>
> Actually I'm suspicious of a "pattern" package. It
> seems way, way too broad:
>
> "The standard Java libraries provides for
> some very common design patterns -
> Comparator/Comparable, EventListener,
> Observer/Observable, Cloneable and Runnable
> However, other generic pattern concepts are
> not supported. The <em>Pattern</em>
> Package provides these extra pattern
> interfaces. It also provides reference
> implementations and utilities for the
> additional interfaces and those
> interfaces in Java."
>
> "[G]eneric pattern concepts" sounds like a recipe for
> hodge-podge. If you want to try out patterns, which
> could be interesting, you definitely want smaller more
> focused packages (e.g. a package devoted to XML
> patterns).
>
> - Morgan
>
> --- Stephen Colebourne <sc...@btopenworld.com>
> 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.
> >
> > > <html>
> > <head>
> > <title>Proposal for Pattern Package</title>
> > </head>
> > <body bgcolor="white">
> >
> > <div align="center">
> > <h1>Proposal for <em>Pattern</em> Package</h1>
> > </div>
> >
> > <h3>(0) Rationale</h3>
> >
> > <p>The standard Java libraries provides for some
> > very common design
> > patterns - Comparator/Comparable, EventListener,
> > Observer/Observable, Cloneable and Runnable
> > However, other generic pattern concepts are not
> > supported. The <em>Pattern</em>
> > Package provides these extra pattern interfaces. It
> > also provides reference
> > implementations and utilities for the additional
> > interfaces and those interfaces in Java.</p>
> >
> >
> > <h3>(1) Scope of the Package</h3>
> >
> > <p>This proposal is to create a package to support
> > low level pattern interfaces.
> > To be included an interface must be simple, have
> > wide potential applicability,
> > and not require a framework.</p>
> >
> > <p>This package also includes utility/reference
> > implementation classes for the pattern
> > interfaces and those pattern classes in java.lang
> > and java.util.</p>
> >
> >
> > <h3>(1.5) Interaction With Other Packages</h3>
> >
> > <p><em>Pattern</em> relies only on standard JDK 1.2
> > (or later) APIs for
> > production deployment. It utilizes the JUnit unit
> > testing framework for
> > developing and executing unit tests, but this is of
> > interest only to
> > developers of the component. Patterns will be a
> > dependency for
> > several existing components in the open source
> > world.</p>
> >
> > <p>No external configuration files are utilized.</p>
> >
> >
> > <h3>(2) Initial Source of the Package</h3>
> >
> > <p>Some initial classes came from the
> > Commons.Collections and Commons.Util
> > subprojects.</p>
> >
> > <p>The proposed package names for the new component
> > are
> > <code>org.apache.commons.pattern.xxx</code> where
> > xxx is the pattern interface name,
> > such as
> >
> <code>org.apache.commons.pattern.comparator</code>.</p>
> >
> >
> > <h3>(3) Required Jakarta-Commons Resources</h3>
> >
> > <ul>
> > <li>CVS Repository - New directory
> > <code>pattern</code> in the
> > <code>jakarta-commons</code> CVS
> > repository.</li>
> > <li>Mailing List - Discussions will take place on
> > the general
> > <em>commons-dev@jakarta.apache.org</em> mailing
> > list. To help
> > list subscribers identify messages of interest,
> > it is suggested that
> > the message subject of messages about this
> > component be prefixed with
> > [Patterns].</li>
> > <li>Bugzilla - New component "Pattern" under the
> > "Commons" product
> > category, with appropriate version identifiers
> > as needed.</li>
> > <li>Jyve FAQ - New category "commons-pattern" (when
> > available).</li>
> > </ul>
> >
> >
> > <h3>(4) Initial Committers</h3>
> >
> > <p>The initial committers on the Lang component
> > shall be as follows:
> > <ul>
> > <li>Stephen Colebourne (scolebourne)</li>
> > <li>Nicola Ken Barozzi (nicolaken)</li>
> > <!-- Add your real name and user name here -->
> > </ul>
> > </p>
> >
> > </body>
> > </html>
> >
> > > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> =====
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Stephen Colebourne <sc...@btopenworld.com>
wrote:
> From: "Morgan Delagrange" <md...@yahoo.com>
> > -1 on moving the comparators package out of
> > Collections. It clearly falls in that domain;
> that's
> > where users would expect to find them.
>
> Then why are there comparators in the Util project?
They are there because they were immature or otherwise
unsuitable for release. All Comparators that we
decided were ready for release were moved from Util to
Collections. Util is an unreleased sandbox component.
> Yes, there is a tendency
> to think of comparators as being collections
> focussed, but they're not. A
> Comparator can be used to compare two objects
> irrespective of whether they
> are in a collection. Therefore they are not in the
> domain of collections
> exclusively.
They're more appropriate in Collections than in
"pattern".
> > Also, all of
> > those comparators are released classes.
> Fine, so they get deprecated
-1 to cavalier deprecation.
> > Actually I'm suspicious of a "pattern" package.
> It
> > seems way, way too broad:
> >
> > "The standard Java libraries provides for
> > some very common design patterns -
> > Comparator/Comparable, EventListener,
> > Observer/Observable, Cloneable and Runnable
> > However, other generic pattern concepts are
> > not supported. The <em>Pattern</em>
> > Package provides these extra pattern
> > interfaces. It also provides reference
> > implementations and utilities for the
> > additional interfaces and those
> > interfaces in Java."
> >
> > "[G]eneric pattern concepts" sounds like a recipe
> for
> > hodge-podge. If you want to try out patterns,
> which
> > could be interesting, you definitely want smaller
> more
> > focused packages (e.g. a package devoted to XML
> > patterns).
>
> I am open to alternative, tighter, wording, but I
> don't want lots of tiny
> projects, each with 2 classes.
It's not the wording that I object to, it's the idea
of a project for "generic patterns" of all shapes and
sizes.
> XML patterns should
> for example be excluded.
> XML is a specific technology, not something generic.
> What the proposal
> should make clear is that these patterns are ones
> that could probably sit in
> java.lang or java.util happily.
Or you could create a series of more focused
components. Maybe you'll be able to provide them as a
single downloadable distribution as well as individual
downloads, but I think you're better off with a more
discrete strategy.
Take it or leave it. You're welcome to fire up a
sandbox component and see how it shakes out (-1 to
moving comparators from Collections though). I think
you'd be better off giving your sandbox some time to
percolate, rather than pushing for a quick release.
> Stephen
>
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Morgan Delagrange" <md...@yahoo.com>
> -1 on moving the comparators package out of
> Collections. It clearly falls in that domain; that's
> where users would expect to find them.
Then why are there comparators in the Util project? Yes, there is a tendency
to think of comparators as being collections focussed, but they're not. A
Comparator can be used to compare two objects irrespective of whether they
are in a collection. Therefore they are not in the domain of collections
exclusively.
> Also, all of
> those comparators are released classes.
Fine, so they get deprecated
> Actually I'm suspicious of a "pattern" package. It
> seems way, way too broad:
>
> "The standard Java libraries provides for
> some very common design patterns -
> Comparator/Comparable, EventListener,
> Observer/Observable, Cloneable and Runnable
> However, other generic pattern concepts are
> not supported. The <em>Pattern</em>
> Package provides these extra pattern
> interfaces. It also provides reference
> implementations and utilities for the
> additional interfaces and those
> interfaces in Java."
>
> "[G]eneric pattern concepts" sounds like a recipe for
> hodge-podge. If you want to try out patterns, which
> could be interesting, you definitely want smaller more
> focused packages (e.g. a package devoted to XML
> patterns).
I am open to alternative, tighter, wording, but I don't want lots of tiny
projects, each with 2 classes. XML patterns should for example be excluded.
XML is a specific technology, not something generic. What the proposal
should make clear is that these patterns are ones that could probably sit in
java.lang or java.util happily.
Stephen
> - Morgan
>
> --- Stephen Colebourne <sc...@btopenworld.com>
> 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.
> >
> > > <html>
> > <head>
> > <title>Proposal for Pattern Package</title>
> > </head>
> > <body bgcolor="white">
> >
> > <div align="center">
> > <h1>Proposal for <em>Pattern</em> Package</h1>
> > </div>
> >
> > <h3>(0) Rationale</h3>
> >
> > <p>The standard Java libraries provides for some
> > very common design
> > patterns - Comparator/Comparable, EventListener,
> > Observer/Observable, Cloneable and Runnable
> > However, other generic pattern concepts are not
> > supported. The <em>Pattern</em>
> > Package provides these extra pattern interfaces. It
> > also provides reference
> > implementations and utilities for the additional
> > interfaces and those interfaces in Java.</p>
> >
> >
> > <h3>(1) Scope of the Package</h3>
> >
> > <p>This proposal is to create a package to support
> > low level pattern interfaces.
> > To be included an interface must be simple, have
> > wide potential applicability,
> > and not require a framework.</p>
> >
> > <p>This package also includes utility/reference
> > implementation classes for the pattern
> > interfaces and those pattern classes in java.lang
> > and java.util.</p>
> >
> >
> > <h3>(1.5) Interaction With Other Packages</h3>
> >
> > <p><em>Pattern</em> relies only on standard JDK 1.2
> > (or later) APIs for
> > production deployment. It utilizes the JUnit unit
> > testing framework for
> > developing and executing unit tests, but this is of
> > interest only to
> > developers of the component. Patterns will be a
> > dependency for
> > several existing components in the open source
> > world.</p>
> >
> > <p>No external configuration files are utilized.</p>
> >
> >
> > <h3>(2) Initial Source of the Package</h3>
> >
> > <p>Some initial classes came from the
> > Commons.Collections and Commons.Util
> > subprojects.</p>
> >
> > <p>The proposed package names for the new component
> > are
> > <code>org.apache.commons.pattern.xxx</code> where
> > xxx is the pattern interface name,
> > such as
> >
> <code>org.apache.commons.pattern.comparator</code>.</p>
> >
> >
> > <h3>(3) Required Jakarta-Commons Resources</h3>
> >
> > <ul>
> > <li>CVS Repository - New directory
> > <code>pattern</code> in the
> > <code>jakarta-commons</code> CVS
> > repository.</li>
> > <li>Mailing List - Discussions will take place on
> > the general
> > <em>commons-dev@jakarta.apache.org</em> mailing
> > list. To help
> > list subscribers identify messages of interest,
> > it is suggested that
> > the message subject of messages about this
> > component be prefixed with
> > [Patterns].</li>
> > <li>Bugzilla - New component "Pattern" under the
> > "Commons" product
> > category, with appropriate version identifiers
> > as needed.</li>
> > <li>Jyve FAQ - New category "commons-pattern" (when
> > available).</li>
> > </ul>
> >
> >
> > <h3>(4) Initial Committers</h3>
> >
> > <p>The initial committers on the Lang component
> > shall be as follows:
> > <ul>
> > <li>Stephen Colebourne (scolebourne)</li>
> > <li>Nicola Ken Barozzi (nicolaken)</li>
> > <!-- Add your real name and user name here -->
> > </ul>
> > </p>
> >
> > </body>
> > </html>
> >
> > > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> =====
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Posted by Morgan Delagrange <md...@yahoo.com>.
-1 on moving the comparators package out of
Collections. It clearly falls in that domain; that's
where users would expect to find them. Also, all of
those comparators are released classes.
Actually I'm suspicious of a "pattern" package. It
seems way, way too broad:
"The standard Java libraries provides for
some very common design patterns -
Comparator/Comparable, EventListener,
Observer/Observable, Cloneable and Runnable
However, other generic pattern concepts are
not supported. The <em>Pattern</em>
Package provides these extra pattern
interfaces. It also provides reference
implementations and utilities for the
additional interfaces and those
interfaces in Java."
"[G]eneric pattern concepts" sounds like a recipe for
hodge-podge. If you want to try out patterns, which
could be interesting, you definitely want smaller more
focused packages (e.g. a package devoted to XML
patterns).
- Morgan
--- Stephen Colebourne <sc...@btopenworld.com>
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.
>
> > <html>
> <head>
> <title>Proposal for Pattern Package</title>
> </head>
> <body bgcolor="white">
>
> <div align="center">
> <h1>Proposal for <em>Pattern</em> Package</h1>
> </div>
>
> <h3>(0) Rationale</h3>
>
> <p>The standard Java libraries provides for some
> very common design
> patterns - Comparator/Comparable, EventListener,
> Observer/Observable, Cloneable and Runnable
> However, other generic pattern concepts are not
> supported. The <em>Pattern</em>
> Package provides these extra pattern interfaces. It
> also provides reference
> implementations and utilities for the additional
> interfaces and those interfaces in Java.</p>
>
>
> <h3>(1) Scope of the Package</h3>
>
> <p>This proposal is to create a package to support
> low level pattern interfaces.
> To be included an interface must be simple, have
> wide potential applicability,
> and not require a framework.</p>
>
> <p>This package also includes utility/reference
> implementation classes for the pattern
> interfaces and those pattern classes in java.lang
> and java.util.</p>
>
>
> <h3>(1.5) Interaction With Other Packages</h3>
>
> <p><em>Pattern</em> relies only on standard JDK 1.2
> (or later) APIs for
> production deployment. It utilizes the JUnit unit
> testing framework for
> developing and executing unit tests, but this is of
> interest only to
> developers of the component. Patterns will be a
> dependency for
> several existing components in the open source
> world.</p>
>
> <p>No external configuration files are utilized.</p>
>
>
> <h3>(2) Initial Source of the Package</h3>
>
> <p>Some initial classes came from the
> Commons.Collections and Commons.Util
> subprojects.</p>
>
> <p>The proposed package names for the new component
> are
> <code>org.apache.commons.pattern.xxx</code> where
> xxx is the pattern interface name,
> such as
>
<code>org.apache.commons.pattern.comparator</code>.</p>
>
>
> <h3>(3) Required Jakarta-Commons Resources</h3>
>
> <ul>
> <li>CVS Repository - New directory
> <code>pattern</code> in the
> <code>jakarta-commons</code> CVS
> repository.</li>
> <li>Mailing List - Discussions will take place on
> the general
> <em>commons-dev@jakarta.apache.org</em> mailing
> list. To help
> list subscribers identify messages of interest,
> it is suggested that
> the message subject of messages about this
> component be prefixed with
> [Patterns].</li>
> <li>Bugzilla - New component "Pattern" under the
> "Commons" product
> category, with appropriate version identifiers
> as needed.</li>
> <li>Jyve FAQ - New category "commons-pattern" (when
> available).</li>
> </ul>
>
>
> <h3>(4) Initial Committers</h3>
>
> <p>The initial committers on the Lang component
> shall be as follows:
> <ul>
> <li>Stephen Colebourne (scolebourne)</li>
> <li>Nicola Ken Barozzi (nicolaken)</li>
> <!-- Add your real name and user name here -->
> </ul>
> </p>
>
> </body>
> </html>
>
> > --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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.
Re: Core architecture [was: Commons architecture]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Colebourne wrote:
> From: "Nicola Ken Barozzi" <ni...@apache.org>
>
>>- I see that there is a need for some more generic interfacts-facades
>>for common things like transforming stuff.
>>So I'm +1 on a transformation package. Is morphos ok for you? Just give
>>it a name and I'll move all my attention to it.
>
> My concern at the moment is that Transformer in [Collections], [Morphos] and
> Convertor in [BeanUtils] all do the same task (essentially). I shall have to
> look at Morphos again soon.
Well, Morphos is simply not there yet ;-)
I haven't committed anything because of the stuff I found in Collections
and Beanutils...
Morphos should really be a facade-interface for all these packages in
terms of transformation:
[Collections] Transformer
[BeanUtils] Convertor
[Cocoon] Transformer-Serializer
[POI] XXXTransformer-XXXSerializer
[Betwixt] itself
[Batik] Transcoder
Basically Morphos incluses also files in the picture, while current
transformation things in [Collections] and [BeanUtils] do not AFAIK.
I think that it makes sense that Morphos is first implemented as a
wrapper to all these, and can be used in the future maybe also as a
common API.
Look in the mailing list archives for the status of the discussion.
>>- I see that there is also a need for interfaces that define *patterns*.
>>Facade, Factory, Command, etc...
>>So I'm +1 for a org.apache.commons.patterns package.
>
> This seems to be gaining ground as a place for these interfaces. Bear in
> mind each will have an assistant Utils class.
You mean a "reference implementations"?
Sure, it's cool :-)
>>As for the interfaces that act as markers or general behaviours, I'm -1,
>>since their behaviour can be enforced only by a container, ie framework,
>>in which they live, such as Avalon.
>>
>>Rule of the thumb: if the interface is a noun, ok. If it comes from a
>>verb, no, since it requires actions from a container, and that is not
>>enforcible here.
>>
>>In fact Avalon core interfaces are basically all "XXXable", because the
>>container acts on them.
>
>
> Following this rule would rule out Identifiable (one method
> getIdentifier()). Now I can sort of see why you are arguing this, but if you
> go that route then what do you do with IdentifiableUtils? IdentifiableUtils
> defines methods for getting a unique identifier. Sample implementations are
> incrementing number, random number, tomcat session id type number. ID
> generation can and should be shared. It just makes sense to me to keep the
> interface with the utility class. Note also that the Identifier generators
> are of course instances of Factory. Things start to connect.
Hmmm, then maybe my rule of the thumb is not so good ;-)
Ok, you correctly tell me that XXXable is also used for things that that
can be reused in different programs without problems, and Identifiable
is a good example.
> I think that we actually don't know what would happen if the Xxxable
> interfaces were in core. My belief is that they would probably be used in
> ways that we wouldn't dream of. Just because its called from a framework at
> the moment doesn't mean it has to be called only from that one framework.
Yes, but the point is consistency.
If you make a generic interface, it's for consistency.
If it's used in ways not forseen, there can be a problem.
Maybe a better rule is: is it a lifecycle interface does it affect the
state of the Component?
In this case Identifiable is ok, since it gets info from a component.
I understand your points, and they make sense.
I also see that you value my concerns, and see that there is a
possibility of doing all this without too many problems.
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 Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Core architecture [was: Commons architecture]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> - I see that there is a need for some more generic interfacts-facades
> for common things like transforming stuff.
> So I'm +1 on a transformation package. Is morphos ok for you? Just give
> it a name and I'll move all my attention to it.
My concern at the moment is that Transformer in [Collections], [Morphos] and
Convertor in [BeanUtils] all do the same task (essentially). I shall have to
look at Morphos again soon.
> - I see that there is also a need for interfaces that define *patterns*.
> Facade, Factory, Command, etc...
> So I'm +1 for a org.apache.commons.patterns package.
This seems to be gaining ground as a place for these interfaces. Bear in
mind each will have an assistant Utils class.
> As for the interfaces that act as markers or general behaviours, I'm -1,
> since their behaviour can be enforced only by a container, ie framework,
> in which they live, such as Avalon.
>
> Rule of the thumb: if the interface is a noun, ok. If it comes from a
> verb, no, since it requires actions from a container, and that is not
> enforcible here.
>
> In fact Avalon core interfaces are basically all "XXXable", because the
> container acts on them.
Following this rule would rule out Identifiable (one method
getIdentifier()). Now I can sort of see why you are arguing this, but if you
go that route then what do you do with IdentifiableUtils? IdentifiableUtils
defines methods for getting a unique identifier. Sample implementations are
incrementing number, random number, tomcat session id type number. ID
generation can and should be shared. It just makes sense to me to keep the
interface with the utility class. Note also that the Identifier generators
are of course instances of Factory. Things start to connect.
I think that we actually don't know what would happen if the Xxxable
interfaces were in core. My belief is that they would probably be used in
ways that we wouldn't dream of. Just because its called from a framework at
the moment doesn't mean it has to be called only from that one framework.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Core architecture [was: Commons architecture]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Colebourne wrote:
> From: "Nicola Ken Barozzi" <ni...@apache.org>
>
>>Avalon is the project that works also to define common interfaces for
>>components.
>>
>>Commons is about common packages.
>
> I would emphasise the word 'components' above.
>
>>This "core" discussion could as well be seen as an attempt to recreate
>>here what Avalon wants to do, but as an Avalon committer, I think it's
>>not the case.
>>
>>If we take the word "framework" away from the proposal and instead focus
>>on specific "API"s, I think it would be great.
>>If we talk about frameworks and patterns, there is Avalon.
>
> Some patterns/interfaces stand alone without needing a component framework
> like Avalon.
True.
>>>transformation - general interface for object transformation
>>
>>+1
>>
>>
>>>type conversion - special application of transformation
>>>
>>>conversion from and to String - special and useful application of type
>>
> conversion.
>
>>>object instantiation - factories and other patterns for instantiation.
>>
> This is actually related to transformation.
>
>>This is about patterns, and I don't see a need for specific APIs.
>>Interoperability here is not needed, unless working in a true component
>>framework, and that's Avalon.
>
>
> Huh?? If transformation is OK, why on earth isn't type conversion? Maybe
> this comment was directed at object instantiation.
this was the case, yes.
> Now there I can
> understand why Avalon would be concerned. After all lifecycle control is a
> key part of Avalon. But come on - Factory is such a generic concept - it
> doesn't need Avalon to survive.
Which is also true... but is there a place for a Factory?
Hmmm.. maybe yes.
>>>pooling - supports different pools and pooling policies. This is
>>
> dependent on instantiation patterns.
>
>>Again, if we talk about a common package for pooling, ok, but keep the
>>"framework" stuff in mind.
>
>
> If pooling were to go in, it would have to be really simple, but that might
> not be the best approach.
>
>
>>>config - <snip>
>>
>
> Config is not core - there are too many different ways to do it (XML, File,
> Network, Framework, ...)
>
>
>>>assertions - related to all issues of type safety in all
>>
>> > packages, esp type safe collections in Commons Collection.
>>
>>This +1.
>>It's a general utility package.
>
>
> Collections are separate from Predicates, which are the two concepts here. A
> Predicate is an if statement expressed as a class. Now if thats not core,
> what is?
>
>
>>>I support the idea of collecting the really general interfaces
>>>(Identifiable, Resetable etc) in a package of its own.
>>
>>If these interfaces are marker interfaces, they have no use.
>>
>>If they are part of a framework, defining them out of a framework will
>>not work.
>>Avalon Framework is the place for it.
>
>
> I disagree with the statement that marker interfaces have no place outside a
> framework. Consider 'Immutable' a marker interface for classes that are
> immutable. Defining it within Avalon would greatly limit its usefulness.
Ahem, I meant to say that marker interfaces have no use - period - ;-)
We deprecated them in Avalon because they are of no use, really.
> BTW: Identifiable is about assigning unique ids to an object. Resetable is
> one of Olas - not sure about that one.
Anyway, let my try to be a bit more clear, and reply to your correct
observations.
Ok, I see a use case here. But maybe not as you say.
- I see that there is a need for some more generic interfacts-facades
for common things like transforming stuff.
So I'm +1 on a transformation package. Is morphos ok for you? Just give
it a name and I'll move all my attention to it.
- I see that there is also a need for interfaces that define *patterns*.
Facade, Factory, Command, etc...
So I'm +1 for a org.apache.commons.patterns package.
As for the interfaces that act as markers or general behaviours, I'm -1,
since their behaviour can be enforced only by a container, ie framework,
in which they live, such as Avalon.
Rule of the thumb: if the interface is a noun, ok. If it comes from a
verb, no, since it requires actions from a container, and that is not
enforcible here.
In fact Avalon core interfaces are basically all "XXXable", because the
container acts on them.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Core architecture [was: Commons architecture]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> Avalon is the project that works also to define common interfaces for
> components.
>
> Commons is about common packages.
I would emphasise the word 'components' above.
> This "core" discussion could as well be seen as an attempt to recreate
> here what Avalon wants to do, but as an Avalon committer, I think it's
> not the case.
>
> If we take the word "framework" away from the proposal and instead focus
> on specific "API"s, I think it would be great.
> If we talk about frameworks and patterns, there is Avalon.
Some patterns/interfaces stand alone without needing a component framework
like Avalon.
> > transformation - general interface for object transformation
>
> +1
>
> > type conversion - special application of transformation
> >
> > conversion from and to String - special and useful application of type
conversion.
> >
> > object instantiation - factories and other patterns for instantiation.
This is actually related to transformation.
>
> This is about patterns, and I don't see a need for specific APIs.
> Interoperability here is not needed, unless working in a true component
> framework, and that's Avalon.
Huh?? If transformation is OK, why on earth isn't type conversion? Maybe
this comment was directed at object instantiation. Now there I can
understand why Avalon would be concerned. After all lifecycle control is a
key part of Avalon. But come on - Factory is such a generic concept - it
doesn't need Avalon to survive.
> > pooling - supports different pools and pooling policies. This is
dependent on instantiation patterns.
>
> Again, if we talk about a common package for pooling, ok, but keep the
> "framework" stuff in mind.
If pooling were to go in, it would have to be really simple, but that might
not be the best approach.
> > config - <snip>
Config is not core - there are too many different ways to do it (XML, File,
Network, Framework, ...)
> > assertions - related to all issues of type safety in all
> > packages, esp type safe collections in Commons Collection.
>
> This +1.
> It's a general utility package.
Collections are separate from Predicates, which are the two concepts here. A
Predicate is an if statement expressed as a class. Now if thats not core,
what is?
> > I support the idea of collecting the really general interfaces
> > (Identifiable, Resetable etc) in a package of its own.
>
> If these interfaces are marker interfaces, they have no use.
>
> If they are part of a framework, defining them out of a framework will
> not work.
> Avalon Framework is the place for it.
I disagree with the statement that marker interfaces have no place outside a
framework. Consider 'Immutable' a marker interface for classes that are
immutable. Defining it within Avalon would greatly limit its usefulness.
BTW: Identifiable is about assigning unique ids to an object. Resetable is
one of Olas - not sure about that one.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Core architecture [was: Commons architecture]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Avalon is the project that works also to define common interfaces for
components.
Commons is about common packages.
This "core" discussion could as well be seen as an attempt to recreate
here what Avalon wants to do, but as an Avalon committer, I think it's
not the case.
If we take the word "framework" away from the proposal and instead focus
on specific "API"s, I think it would be great.
If we talk about frameworks and patterns, there is Avalon.
Avalon is the "commons" of the Apache Server Framework, as of our charter.
Ola Berg wrote:
> A list with a few examples:
>
> transformation - general interface for object transformation
+1
Morphos is an attempt to start such a thing.
Call it morphos, call it transformation, I'm +1.
> type conversion - special application of transformation
>
> conversion from and to String - special and useful application of type conversion.
>
> object instantiation - factories and other patterns for instantiation. This is actually related to transformation.
This is about patterns, and I don't see a need for specific APIs.
Interoperability here is not needed, unless working in a true component
framework, and that's Avalon.
> pooling - supports different pools and pooling policies. This is dependent on instantiation patterns.
Again, if we talk about a common package for pooling, ok, but keep the
"framework" stuff in mind.
> config - the pattern \"Object recieves config data\" is already present in Avalon.
> My idea of \"Configurator configures objects out of config data and keeps
> track of state, persistance and updates\" (related to pooling and
> factories and type conversion) is not present anywhere else than in my
> nu.viggo.* classes from what I have seen.
?
Avalon does not work as you say. What you call Configurator is in fact
the container of the components, and it does keep track of all these.
> assertions - related to all issues of type safety in all
> packages, esp type safe collections in Commons Collection.
This +1.
It's a general utility package.
> younameit - (Jon, tell us about your ideas, chances are that we have been thinking along the same lines)
>
> Some of these might actually be better off in a separate project (so that the scope doesn\'t grow to much), but one can easily see that there are some common interfaces that some classes need to implement in order to acheive this inter-operability between packages.
> I support the idea of collecting the really general interfaces
> (Identifiable, Resetable etc) in a package of its own.
If these interfaces are marker interfaces, they have no use.
If they are part of a framework, defining them out of a framework will
not work.
Avalon Framework is the place for it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Core architecture [was: Commons architecture]
Posted by Steven Caswell <st...@caswell.name>.
I want to throw a different light on the topic as well. When I think of
core commons, I think more along the lines of basic, low-level
functionality, just above the java API. For example, there are a great
set of classes in Ant the implement functionality to invoke run-time
operating system commands. I'm thinking these ought to be extracted into
a commons package so that the world can share in their usefulness. So I
think of this as core. It is not really framework stuff, but it is a
level above the Java API.
Maybe I'm on a different wavelength. Is what I described in anyone
else's thinking about a commons core?
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Sunday, June 23, 2002 5:49 PM
> To: Jakarta Commons Developers List; Ola Berg
> Subject: Re: Core architecture [was: Commons architecture]
>
>
>
> Focusing on your examples, I see no sections for the
> 'utility' functionality involved in Lang/Net/IO/. Instead
> your definition of Core seems to be some kind of framework
> that I as a developer would adhere to to get better type-safety etc.
>
> In fact the list seems to get more from BeanUtils
> [conversion], DBCP(?) [pooling], Collections et al [transormation].
>
> In fact, it seems more that the idea is for an Avalon like
> general framework. Now, I don't pretend to understand the
> Avalon design, but at a time when Avalon is refactoring out
> their most common components into Commons, it seems a poor
> move for us to start trying to build a common framework. Does
> Avalon already have this?? Would this be better placed as a
> low-level part of the Avalon framework?
>
> What projects in Commons would be consumers of this Core
> framework? Is it a case where the util-like projects would
> not, but the baby-projects would?
>
> I'm not arguing against the concept of a
> core-framework-interface project that others adhere to, but I
> do think it is a different concept to the current utility
> projects which aim to be at the core of Commons.
>
> Hen
>
> On Mon, 24 Jun 2002, Ola Berg wrote:
>
> > My first question deals with the scope of Core. And when I
> speak about
> > scope, I am not referring to packages but to mechanisms, what
> > mechanisms should Core support (division into packages could be a
> > later issue).
> >
> > A list with a few examples:
> >
> > transformation - general interface for object transformation
> >
> > type conversion - special application of transformation
> >
> > conversion from and to String - special and useful
> application of type
> > conversion.
> >
> > object instantiation - factories and other patterns for
> instantiation.
> > This is actually related to transformation.
> >
> > pooling - supports different pools and pooling policies. This is
> > dependent on instantiation patterns.
> >
> > config - the pattern \"Object recieves config data\" is already
> > present in Avalon. My idea of \"Configurator configures
> objects out of
> > config data and keeps track of state, persistance and updates\"
> > (related to pooling and factories and type conversion) is
> not present
> > anywhere else than in my nu.viggo.* classes from what I have seen.
> >
> > assertions - related to all issues of type safety in all
> packages, esp
> > type safe collections in Commons Collection.
> >
> > younameit - (Jon, tell us about your ideas, chances are
> that we have
> > been thinking along the same lines)
> >
> > Some of these might actually be better off in a separate
> project (so
> > that the scope doesn\'t grow to much), but one can easily see that
> > there are some common interfaces that some classes need to
> implement
> > in order to acheive this inter-operability between
> packages. I support
> > the idea of collecting the really general interfaces (Identifiable,
> > Resetable etc) in a package of its own.
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Core architecture [was: Commons architecture]
Posted by Henri Yandell <ba...@generationjava.com>.
Focusing on your examples, I see no sections for the 'utility'
functionality involved in Lang/Net/IO/. Instead your definition of Core
seems to be some kind of framework that I as a developer would adhere to
to get better type-safety etc.
In fact the list seems to get more from BeanUtils [conversion], DBCP(?)
[pooling], Collections et al [transormation].
In fact, it seems more that the idea is for an Avalon like general
framework. Now, I don't pretend to understand the Avalon design, but at a
time when Avalon is refactoring out their most common components into
Commons, it seems a poor move for us to start trying to build a common
framework. Does Avalon already have this?? Would this be better placed as
a low-level part of the Avalon framework?
What projects in Commons would be consumers of this Core framework? Is it
a case where the util-like projects would not, but the baby-projects
would?
I'm not arguing against the concept of a core-framework-interface project
that others adhere to, but I do think it is a different concept to the
current utility projects which aim to be at the core of Commons.
Hen
On Mon, 24 Jun 2002, Ola Berg wrote:
> My first question deals with the scope of Core. And when I speak about
> scope, I am not referring to packages but to mechanisms, what
> mechanisms should Core support (division into packages could be a
> later issue).
>
> A list with a few examples:
>
> transformation - general interface for object transformation
>
> type conversion - special application of transformation
>
> conversion from and to String - special and useful application of type
> conversion.
>
> object instantiation - factories and other patterns for instantiation.
> This is actually related to transformation.
>
> pooling - supports different pools and pooling policies. This is
> dependent on instantiation patterns.
>
> config - the pattern \"Object recieves config data\" is already
> present in Avalon. My idea of \"Configurator configures objects out of
> config data and keeps track of state, persistance and updates\"
> (related to pooling and factories and type conversion) is not present
> anywhere else than in my nu.viggo.* classes from what I have seen.
>
> assertions - related to all issues of type safety in all packages, esp
> type safe collections in Commons Collection.
>
> younameit - (Jon, tell us about your ideas, chances are that we have
> been thinking along the same lines)
>
> Some of these might actually be better off in a separate project (so
> that the scope doesn\'t grow to much), but one can easily see that
> there are some common interfaces that some classes need to implement
> in order to acheive this inter-operability between packages. I support
> the idea of collecting the really general interfaces (Identifiable,
> Resetable etc) in a package of its own.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>