Which proofs I'm completely out of the loop! Sound all great to me! Marc
> -----Original Message----- > From: Nicola Ken Barozzi [mailto:nicolaken@;apache.org] > Sent: Tuesday, November 12, 2002 11:55 PM > To: Avalon Developers List > Subject: Re: PMC et al > > > > Marc Schier wrote: > > Hi all, > > > > I've resurfaced after a stressfull re-location to my new > home in Seattle. > > Was a lot of work! Now after setting up my email access at > work I discovered > > 672 new mails in the Avalon-Dev folder. Sure a lot of > things have been > > going on. Now of course I'm writing the following without > really knowing if > > it is still up for discussions or has already been decided. > > > > > >>Part of our problems has come from dividing implementations > >>and creating > >>feuds, so I would propose that: > >> > >> 1) the Components/services would eventually migrate to > >>Apache Commons. > >> not now, not tomorrow, but the path is set, and other projects > >> like Turbine will follow :-) > > > > > > I absolutely agree in seperating commit privileges and > creating several > > PMCs, but I'm not sure if I'm convinced that it's the right > thing to move > > "all" components to commons, if that's what's suggested. > > > > Apache commons IMO as it stands right now is mostly > non-component and > > largely library material. I think it's a very good > approach to centralize > > this tooling development effort within Apache, and maybe > 30% of excalibur > > should actually be in there (CLI, Concurrent, event...), > but I do not think > > pure Avalon-services will fit, since they cannot easily be used in > > Non-Avalon environments. They do not represent the > classical software > > tooling. > > We're talking about Apache Commons > (http://commons.apache.org) for the > Components, not Apache Jakarta Commons > (http://jakarta.apache.org/commons/). > > Your comment is correct, Jakarta Commons never accepted our > components > and never will, but Apache Commons IIUC will, and Peter > Donald is on the > PMC :-) > > > They rather perfectly fit into execution environments like Avalon > > containers. > > > > In my opinion the first thing to do is to place the > mentioned 30% into > > Commons. I don't see why that has not been done faster > anyway, since it > > will not effect more than build.xmls anyway. > > It has been partially done, and also mainly agreed upon, but > it's mostly > lack of time by developers. > What was possible has been done, and we also merged some of our stuff > with J-C stuff, and the result seems very good :-) > > > ( BTW How do you get commit > > privileges in commons? ) > > In Jakarta-Commons-Sandbox, just ask and you will be given. > > >> 2) we keep only *one* set of utility classes called avalon-util > >> (no more fancy names, pleeease) > >> > >> 3) all containers in the making, like Merlin2 and Fortress > >> go in the scratchpad dir. > >> > >>This should *not* be done hastly, it will take time. But > >>we'll get there. > >> > >>In the end we will have *one* avalon CVS repo, with > >> > >> ./src/framework/**.java > >> ./src/util/**.java > >> ./scratchpad/src/merlin2/**.java > >> ./scratchpad/src/fortress/**.java > >> > >>Some classes now in framework will go in util too probably, > >>we'll have > >>to vote case by case. > > > > > > Excellent idea. Makes perfect sense to me. Nonetheless I > think we need a > > service/component repository as well independent from > Commons to promote the > > Avalon development and adoption of the framework. > > The repository should also be open to Turbine, Obj, Cocoon, etc > developers to place their stuff there, so putting it on common ground > seems more sensible to me. > > Apache Commons will have different bylaws that Jakarta Commons, thus > making this part of its repo effrectively the Avalon > Component Repository. > > > If we want developers and decision makers to know that > Avalon promotes > > re-use we have to provide them with reusable components as > well and IMO from > > one homogenious source. > > Been there, done that. IMHO it seems that Cornerstone was not > a massive > hit and that otehr projects would like to cooperate more in the > process... IMHO that is. > > > So why not make Excalibur the Component Repository for Avalon after > > migrating the containers, utils and commons material? PMC > would have commit > > privileges to framework, but for the repository we could be > more generous > > and have more developers be able to add and work on service > implementations > > compliant to framework and running inside an avalon > container (kinda like a > > micro-sourceforge). To promote Avalon development, we > could e.g. establish > > an active web based community where users could vote on the > usefulness of a > > particular service implementation. > > Exactly what we are thinking to do with Apache Commons. > But Apache Commons has just started, we'll see that the > solution will be > accepted by all and be solid. > > As far as the concept of making such a place is agreed on, we > can always > discuss the details and actual locations later. > > > As far as Phoenix is concerned, why not spinning it off as > a seperate > > project? This could give this excellent piece of software > more market > > recognition than just being a sub project of Avalon. > > > > So where am I in the course of the discussion? > > Seems you're on the spot :-) > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - 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> > -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
