commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: The exegesis
Date Mon, 12 Aug 2002 17:18:12 GMT
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 

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. 


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message