commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertdon...@mac.com>
Subject Re: [OT] What's in a component?
Date Thu, 10 Jan 2002 18:53:37 GMT
i (personally) started using the term 'component' rather than subproject 
for the stuff in the commons since "commons sub project" is confusing 
because jakarta is an apache project and jakarta-commons is a jakarta sub 
project. the commons charter talks about packages but using this word is 
also confusing (since some components contain code in more than one java 
package).

you make some interesting points but i don't have any answers...

- robert


On Thursday, January 10, 2002, at 12:59 PM, Fernandez Martinez, Alejandro 
wrote:

> Hi folks!
>
> I've followed (as best I could) the discussions here and on 
> general@jakarta,
> about making components reusable and sharing them. However, an old doubt 
> of
> mine arises now and again: what is a component? Or, if you prefer an
> operative definition, what are the necessary steps to make a bunch of code
> into a component? Sun's Java site, for example, talks all the time about
> them, without defining the term; and even when they are a standard member 
> of
> UML diagrams, I've never seen the concept discussed.
>
> I will now expose my musings on the subject. They are just a gross
> approximation but, lacking a more accurate description, it can serve as a
> starting point.
>
> I think that the notion of 'component' must be closely related to what a
> 'framework' is. Only inside a framework can you define what entities can
> reside inside it, and call them 'components'. Also, when you have a bunch 
> of
> 'components', you can call that a 'framework'.
>
> But the term hints at 'independence' too, as if they could live on their 
> own
> (which is seldom the case). Even worse when 'reusable' is added. Any piece
> of code needs a basic set of services, usually the same, that must be
> provided somehow -- if the framework does not, or there is no framework,
> then the user should.
>
> Now, going to the operative side of the question: what problems do arise
> when trying to make components really independent? E.g., take them from
> their craddle framework and put them in Commons. They are quite often the
> same: build, discovery, log, communication, error management and
> configuration. You can surely add a few more of your own.
>
> It's probably not the time to enter a point-by-point discussion, for those
> that are still reading this far. As a general remark, some of these issues
> are no problem in Jakarta land: the build tool (ant) is standardized, and
> error management only lacks a firm criteria for checked exceptions. Others
> are more tricky: there's a logging component (log4j), but some people have
> decided to go in other directions, and a common interface (logkit) has 
> been
> built. Still others are a complete mess, such as component discovery and
> configuration.
>
> I think that at least part of the misunderstandings come from not agreeing
> on what a 'component' is supposed to be inside Commons. I hope someone can
> throw a bit of light into this matter, so that all of us can tell a 
> Commons
> component from a mile off.
>
> Un saludo,
>
> Alex Fernández.


--
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