avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [PROPOSAL] Avalon Components
Date Sat, 11 Jan 2003 20:15:22 GMT

Leo Simons wrote:
> Nicola Ken Barozzi wrote:
>>>> More practically, it would unite Excalibur and Cornerstone, and make 
>>>> it possible for James developers to fix the Cornerstone components 
>>>> that are driving them mad directly in the repository, and facilitate 
>>>> the usage and fixing of our components by interested Turbine 
>>>> developers.
>>> big advantage!
>> Ok, let's see then how to make it happen. :-)
> yep.


>> MHO is that it still doesn't make sense to have a completely common 
>> component repository.
> also agreed. I think we should make a distinction between component and 
> component. I think we should seperate based on usage space:
> - framework development (1)
> - container development (2)
> - application framework development (3)
> - application development (4)
> (1),(2) ==> in avalon
> (3) ==> okay in avalon, but preferably elsewhere in the future
> (4) ==> elsewhere
>>> On my agenda is asking: "Guys, can we move components X, Y, Z 
>>> currently in cvs module A, B, C over to Commons?"
>>> And then doing it. Until I see a definitive "no" answer I'm not 
>>> liking "Avalon Components".
>> no, then.
>> I'm (vote) -1 towards moving them into Commons now. In the future, 
>> yes, but not now. Moving them there would refragment our community 
>> with what benefits?
> removing fragmentation of the apache community of course!


>> I only see negative things of doing this /now/.
>> I repeat that I like the concept of a common repository, but I 
>> question the benefits of doing it /now/.
> ok.


>> I'm talking about *Avalon" Components, ie those that had the 
>> "Component" interface, to be clear. Anything that is not *strictly* an 
>> Avalon Component-Service should (or I'd even say must) go elswhere, 
>> and my favourite place for it is in Jakarta Commons, as has been done 
>> till now.
> note that the difference between an "*Avalon* Component" and another 
> component is  often just a compile-time and runtime dependency on 
> avalon-framework.jar, as well as sometimes some renaming of methods. You 
> shouldn't make a distinction based on that.

Of course, having a couple of Avalon methods would just be fooling, I agree.

> I think we should strive to move components in (3) or (4) (which are not 
> used in building other parts of avalon (ie user space code)) elsewhere 
> as well. KISS.
>> As for utility code for making containers, it should all go in the 
>> container that uses them, because we will be making a single container.
> not against it (ie I find all that stuff takes a lot of work and there 
> must be another reason than "it is clean" for me to do that work).

Agreed. As we agree on the principle, when we will start uniting 
containers you will see that other things will follow. I'm also against 
doing it just for the sake of it.

>>    _framework_
>>      Avalon4  ----------------------------------- AvalonFive-F
> note that perhaps:
>     2001    ----------------------------------- 2022

Could be. I'm with you in stressing that A4 is something we should build 
upon. Anyway, it's the container evolution that presses me, not the 

>>    _container_
>>      ECM ---- Fortress ---- Merlin's Fortress-----AvalonFive-C
>>                          ^                     ^
>>                          |                     |
>>      Merlin (unreleased)-'                     |
>>                                                |
>>                                                |
>>      Phoenix ----------------------------------'
> I think your AvalonFive-C should actually just be an Avalon4 container, 
> and that "Merlin's Fortress" shouldn't be removed as a step...Other than 
> that, yep! so:
>      ECM ---- Fortress --------- SuperAvalonC ---------AvalonFive-C
>                          ^
>                          |
>      Merlin (unreleased)-'
>      All other dev code -'
>      (like containerkit)-|
>                          |
>      Phoenix ------------/---------maintaince-only----retire
> but this should go under the roadmap thread....

Yes, these two threads have some overlap.
My roadmap was based on what I read on this list, but I also had 
concerns about it being too baby-stepped.

Yes, I like yours better.

>>   _components_
>>             Jakarta Commons
>>                    ^
>>                    |
>>                 (utils)
>>                    |
>>      Excalibur ------------ Avalon Components --(*)-- Apache Commons
>>                       ^   ^                        ^
>>      Cornerstone -----'   |                        |
>>                           |                        |
>>      Cocoon Components ---'                        |
>>                                                    |
>>      Turbine Fulcrum ---(*)------------------------'
> ehm...ok...But I really have absolutely no desire to go through all the 
> work to do lots of cvs and package migration. 

Hold it! Who said that? No package will change. I see now why you may 
think I'm nuts! ;-)

> I have some different 
> priorities.
> And I have lots of demands about how to do it if others are to do this 
> work (like it has to be started and _finished_ within a reasonable time 
> frame (ie not like the previous refactoring attempts), it needs to work 
> with gump, it needs to be easily maintainable by peopl as dumb as me, it 
> should be backwards-compatible, it needs to satisfy actual need, it 
> needs clear documentation, ......)

Yes, Yes, Yes. See below.

>>> Nor do I think it is of interest to the james or turbine developers 
>>> to work on _those_ components.
>> It is. James uses Cornerstone components that are now bugged. They 
>> want to fix them. I think it's in the best interest of both of us 
>> projects to make it happen.
> Cool.
> way easier: I'm supportive of granting all james committers voting & 
> commit privelidges wrt the cornerstone repo. It's a lot less work than 
> doing lots of confusing cvs/package/whatever migration!

Ok, here is how I thought we could do Avalon Components:

  1   - rename jakarta-avalon-excalibur CVS module to avalon-components
  1-b - symlink so that you can checkout it as jakarta-avalon-excalibur
        for some time
  2   - move the cornerstone component dirs under that repo (simple cp)
  3   - add them in the "excalibur" build

This would make us almost instantly have a common repo for all 
components that we can open to the James committers as you say.

The only real work would be to add them to the build of "excalibur", 
which is not a big feat.

This would be a first step; in the meantime we can still migrate package 
per package of non-Avalon stuff to JC, and decide about the others as we 
proceed. But in the meantime this would mean that we have taken a step 
towards a single component system, and towards a tighter relationship 
with our users.


Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message