commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: The exegesis
Date Mon, 12 Aug 2002 20:05:43 GMT
Costin,
Thank you for your clear post. The debate over [pattern] got confused along
the way. I have just outlined in another mail what I see [pattern] as and
how it is not Avalon.

It really is NOT as simple as interface == Avalon. (At present, Avalon ==
COP - Component oriented programming, [pattern] has nothing to do with
components).

My intent is to add to [pattern], almost certainly as sole committer. It is
my opinion that with more interfaces, the intent will be clearer. I have no
intention to aim for a promotion anytime soon.

(Note, these comments exclude Predicate, Transformer, Command/Closure, and
Factory. These are callbacks, and a totally different type of thing which
shouldn't have ever been associated with [pattern].)

Stephen

----- Original Message -----
From: <costinm@covalent.net>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Monday, August 12, 2002 6:18 PM
Subject: RE: The exegesis


> I won't respond to each individual email in this thread.
>
> I announced that I would -1 any component that requires changes in the
> API of projects that use it. I'm not an avalon commiter. The
> reason I sugested avalon for the [patterns] and lifecycle is that
> they already have this kind of stuff and it may fit there.
>
> I don't think lifecycle interfaces fits the commons, and I don't think
> creating intefaces and design for other projects to use fits with the
> commons.
>
> You can still get [pattern] and lifecycle into commons - all you need
> is a majority. I'll vote -1 and I'll vote -1 on each component that would
> want to depend on this kind of commons component and I'll -1 on each
> project where I'm a commiter that wants to use this. In each case it's
> a majority vote - so it may happen or not.
>
> If other people vote -1 because they feel the lifecycle interface or
> aproach to lifecycle in avalon (or tomcat or ant or any other project ) is
> better - that's a valid vote IMHO. If the vote -1 because they feel only
> avalon can define lifecycle - I don't think that's  valid.
>
> For the record, tomcat defines and uses at least 3 lifecycle patterns -
> one implementing the servlet API lifecycle, one in tomcat3 ( for
> inteceptors ) and one if tomcat4 ( Lifecycle interface ). You could
> also count the lifecycle patterns used for jsp tags.
> Ant also defines a lifecycle for tasks ( without requiring any interface!)
> Almost each project uses the pattern in a specialized way, acording
> to their needs.
>
> There is a difference between 'pattern' and API - I'm all for
> (consistent) design patterns, but I'm against commons getting into
> the business of defining interfaces for patterns.
>
> That's my view on the scope of commons - and I won't change my
> mind. If you feel a majority wants commons to define interfaces -
> propose [pattern] for a vote. Until commons is accepted in commons
> proper - there is no point of discussing who should depend on it.
> And for each component to add an extra dependency we should
> have a vote.
>
> This doesn't mean you shouldn't work on [pattern] or that I think
> patterns is bad - I just don't think commons is the right place
> for it. You can propose a new top-level project, or use sourceforge,
> or avalon, or any project that feels this is in its scope - the code will
> be the same.
>
>
> To quote Tim Moore:
>
> > IMO, commons seems to work best when one Jakarta project sees a
> > component in another one that they want to reuse, and that component is
> > factored out to be independent of the original project.  My experience
> > has been that when people try to create components with the intent of
> > reuse without having an actual concrete use first, they end up creating
> > something overly complex that doesn't really suit anyone.
>
> That's my opinion as well.
>
> Costin
>
>
>
>
> --
> 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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message