avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: Framework -> Stable ???
Date Tue, 03 Apr 2001 14:24:01 GMT
At 03:16  3/4/01 +0200, Leo Simons wrote:
>> * If it is a component we don't stabilize it yet
>> * If it is not sufficiently general or only applicable "in theory" then we
>> don't stabilize it yet
>> * If it is utility code then we only stabilize it if (1) directly uses it
>> or C2 and it's clients will use it.
>>
>> Given this I propose that the following 2 hierarchies
>> * org.apache.framework (stable framework code)
>> * org.apache.avalon (unstable/untested code or components)
>
>I have my doubts about the name "framework" as this removes the
>direct reference to Avalon, which is not wise from a marketing POV.

actually that was one of the issues I was trying to address ;) When people
hear avalon they tend to think of a particular part of it

* cocooners think of framework part or components part (ie pool/datasource*).
* general jakarta peeps think of it as an application server
* some people think of it as a repository of utility code etc

I know it would be nice to brand it "avalon" or something it is just how we
do it that matters ;)

>perhaps org.apache.avalon for the framework
>and org.apache.avalon-util (.aut) for utilities
>and org.apache.cornerstone for the components?

Well cornerstone is components hosted by the kernel so IMHO it is not
really appropriate for free standing components.

In an absolute ideal situation I would like to see

org.apache.aut.* (utility)
org.apache.avalon/framework.* (framework)
org.apache.agora/???.* (components)

however I don't have the cycles for that at the moment - especially not if
we plan to go beta by the time c2 goes beta. So hence the compromise ;)
Though if someone else wanted it badly enough ...

>> I will update the proposal directory with an outline of what I believe is
>
>have you tried building from it yet? There are many import statements to
>be updated there. I fixed the majority on my home system, but I can't
>commit them because of cvs probs :-(.

I fixed them today but I haven't checked in my changes .. will do it real
soon now ;)

>> Anyway thats the basic outline of something we can do. One thing I do have
>> a query about is whether we want to keep the interface "Component" around.
>> Currently "Component" is what is returned from ComponentSelector and
>> ComponentManager which means that any components stored in those objects
>> must implement COmponent. This can be a PITA when you want to store JDK
>> type objects in the CM - I have run afoul of it a number of times and have
>> a number of classes who only exist to implement Component. Hence I would
>> like to make CM and ComponentSelector return Object instead and completely
>> remove the Component interface.
>
>I've seen the problem too. But the disadvantage is the removal of the
>conceptual
>"Component". A way to avoid that would be to have
>
>Component ComponentManager.generateComponentFrom(java.lang.Object object);
>
>which wraps the thing. Might be some complicated rtti stuff there, though.

yep I am not really sure how to handle this ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message