Re: [PROPOSAL] Avalon Components

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.

>>> There were two issues brought up about this happening.
>>>
>>> Leo Simmons correctly reminded that there is an Apache Commons 
>>> project, that could make a cool repository for all Avalon Components 
>>> for all Apache projects.
>>>
>>> IMHO we are still far away from that possibility. I really don't 
>>> think that in the short-mid term Turbine or James developers would 
>>> want to move their stuff into that repo, because there is no real 
>>> need. What they would do, is to partecipate in the *generic* 
>>> components, that we would keep here, in Avalon Components.
>>
>> IMO all it takes is someone 'just doing it'. Apache Commons is just 
>> about ready for some components. I'm not saying the turbine or james 
>> developers would need to move their components, but if we move ours 
>> they can still get access as well....
> 
> This is not a reason for moving to Apache Commons though.

yep. The reason for moving to Apache Commons is that that is a location 
for 'common' components, whereas Apache Avalon is not.

> 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 so very much against "Yet Another Commons" . . . . Jakarta 
>> Commons, XML Commons, Apache Commons, Avalon Commons, James Commons, 
>> Cocoon Commons.......it's simply doesn't make sense. And I'm not even 
>> talking about the negative vibes it'll send through the wider 
>> community (based on experience from the reorg@apache list).
> 
> Ok, then, your point is valid, let's remove the Component "Sandbox" 
> part. I think your observation on this is correct. We have our Avalon 
> Sandbox for the Avalon core committers stuff. For Avalon Components 
> there would be no sandbox then, ok.

good.

>> We've got two kinds of components:
>>
>> - those useful in a very wide scope, like Zip or Datasource
>> - those useful only (mostly) in developing avalon containers or 
>> infrastructure on top of avalon, like instrument, extension, 
>> containerkit....
>>
>> for the first one, that should go to a _common_ commons. For the 
>> second one, if it makes sense to have those seperated out into a 
>> different cvs, okay. 
> 
> Leo, I think we had already decided this, sorry if I was not clear.
> 
> 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.

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

>    _framework_
> 
> 
>      Avalon4  ----------------------------------- AvalonFive-F

note that perhaps:
	2001    ----------------------------------- 2022

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

>   _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. 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, ......)

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

cheers,

- Leo