Re: [PROPOSAL] Avalon Components

Leo Simons wrote:
> Hi Nicola,
> 
> Nicola Ken Barozzi wrote:
> <snipping lots of stuff/>
> 
>> The main reason to make this here at Avalon is to have real contact with
>> the users of Avalon, and have them actively partecipate in the component
>> development. Avalon has had great benefit from the partecipation had in
>> the last month of outer-avalon developers of projects that use Avalon,
>> and we would like it to continue.
> 
> +1.
> 
>> 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. :-)

>> 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. We can still 
make them partecipate in "our" components.

MHO is that it still doesn't make sense to have a completely common 
component repository.

> 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? Move things that we count on and are stable under SVN that we 
decided not to use for container stuff yet, and move the community out?

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

>> I have not yet recieved public answer from the question I gave to the 
>> board about this. TO resolve this, I propose that we ask the board to 
>> retify an addendum at the next meeting for our charter *if* they 
>> decide that it's needed for this subproject creation:
>>
>>   RESOLVED, that the Avalon PMC be and hereby is responsible
>>   for the creation and maintenance of software related to
>>   component and service management, and components and services
>>   themselves designed to operate in it, based on software licensed
>>   to the Foundation;
> 
> 
> 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.

But Stephen is talking about an Avalon "playground", a slightly 
different notion, let's then remove this notion from this porposal and 
focus on the Components repo.

Avalon Components is *not* a Avalon Commons. It's about the Components 
*we* make. I'd never ever ask Turbine and James to move their Components 
here, unless they have a compelling reason to, like Cocoon does with 
excalibur components.

We are still making the container that will make Components completely 
compatible. Until then, I don't see a compelling reason to switch to a 
new repository in a new project with a new VCS system.

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

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.

[()*=eventually]

    _framework_


      Avalon4  ----------------------------------- AvalonFive-F


    _container_

      ECM ---- Fortress ---- Merlin's Fortress-----AvalonFive-C
                          ^                     ^
                          |                     |
      Merlin (unreleased)-'                     |
                                                |
                                                |
      Phoenix ----------------------------------'



   _components_


             Jakarta Commons
                    ^
                    |
                 (utils)
                    |
      Excalibur ------------ Avalon Components --(*)-- Apache Commons 

                       ^   ^                        ^
                       |   |                        |
      Cornerstone -----'   |                        |
                           |                        |
                           |                        |
      Cocoon Components ---'                        | 

                                                    |
                                                    |
      Turbine Fulcrum ---(*)------------------------'




> But that certainly doesn't require amendment of the board 
> resolution.

Based on Stephen's comments, it could be. I think it doesn't, I was 
trying to consider his concerns.

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

-- 
Nicola Ken Barozzi                   [email protected]
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------