commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Caswell" <ste...@caswell.name>
Subject RE: Core architecture [was: Commons architecture]
Date Sun, 23 Jun 2002 23:06:34 GMT
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: <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