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. :-)
This is not a reason for moving to Apache Commons though. We can still make them partecipate in "our" components.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....
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?"no, then.
And then doing it. Until I see a definitive "no" answer I'm not liking "Avalon Components".
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/.
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.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).
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:Leo, I think we had already decided this, sorry if I was not clear.
- 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.
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)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
