Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 58965 invoked from network); 1 Dec 2002 22:05:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Dec 2002 22:05:38 -0000 Received: (qmail 25973 invoked by uid 97); 1 Dec 2002 22:06:45 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 25942 invoked by uid 97); 1 Dec 2002 22:06:44 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 25930 invoked by uid 98); 1 Dec 2002 22:06:44 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DEA882C.7040700@apache.org> Date: Sun, 01 Dec 2002 14:07:40 -0800 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Auto-assembly References: <200211262314.00244.peter@realityforge.org> <200211280755.15818.darrell@apache.org> <3DE9F0BB.6020900@apache.org> <200212020528.55126.darrell@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Darrell DeBoer wrote: > On Sun, 1 Dec 2002 21:21, Stefano Mazzocchi wrote: > >>Darrell DeBoer wrote: >> >>>On Thu, 28 Nov 2002 04:45, Stefano Mazzocchi wrote: >>> >>>>Nobody is proposing to stop Phoenix development, Peter. Stop crying. >>> >>>Ummm, Stefano, you might want to read the entire content of the emails >>>you send. This one seems self-contradictory. Or just a troll. >>> >>>(from further up you email) >>> >>> >>>>>On Wed, 27 Nov 2002 18:30, Nicola Ken Barozzi wrote: >>>>> >>>>>>We are discussing about a new single container with profiles, wouldn't >>>>>>be better to put all further development on hold, switch to >>>>>>maintainance mode and focus on that? >>>>> >>>Sounds like someone proposing to stop Phoenix development to me. >> >>Nicola proposed to put on hold 'further development' of Phoenix. Which >>(at least to me) means: let's top having containers as playgrounds for >>framework-related stuff that should be discussed and voted by the avalon >>development community. >> >>My response was that nobody here is proposing to 'shut down phoenix' and >>stop its development and leave all the phoenix users with nothing to >>work on and without bugs to be fixed. >> >>So, one thing is 'development', another thing is 'further development'. >>But you're right, it wasn't clear, so thanks for asking me to clarify. >> >>What I want to see ending is the use of containers to implement stuff >>that influence Avalon as a framework and create 'dialects' of framework >>usage. >> >>This is what Nicola is proposing to stop. >> >>This is what I agree on. >> >>If the community agrees on this proposal, Phoenix (and all the other >>containers controlled by the Avalon development community) will >>implement what the Avalon community decides and all the >>framework-related decisions will have to go thru community consensus. >> >>This will, hopefully, reduce current Avalon 'balkanization'. >> >>If the community agrees on this proposal and single developers want to >>go ahead without community consensus they can: >> >> 1) follow the rules of revolutionaries >> >> 2) go somewhere else >> >>There is no other alternative around here. >> >>All avalon developers must understand that. > > > Thanks for the clarification. I must say that as a James developer and a > Phoenix user, I'm really against any proposal that would slow down the > provision of new and *necessary* features in Phoenix. The proposal is not meant to 'slow down' anything, Darrell. It's meant to put an end on fragmentation of avalon implementations. > We waited a *long* time for a stable, released version of Phoenix. And it's > great, but we want more. We want to be allow developers to simply "drop-in" a > mailet jar file with some config and for it to just work. Dude, I hear you. Cocoon needs *exactly* the same hotdeployment capabilities. What we want it to have *all* the avalon developers working on solving the same issues *together*. That might be harder and slow at first, but this is a long-term goal: provide a united and strong avalon development community that will concentrate on functional requirements of all the avalon users, but without fragmenting the avalon brand into myriads of different containers. > I personally want > it to be easier to compose components of finer grained sub-components. These > sorts of features probably require new features (like auto-assembly) for > Phoenix. Exactly. But if you talk about this on phoenix-dev or james-dev, the other people that use Cocoon and have similar issues, will not be able to suggest things. Or you to them. See my point? we are not trying to blast Phoenix or to kick people out, rather the opposite: we want to work together for a better Avalon! > We're about to commence on a bunch of new developments in James, and I for one > want to continue on top of the stable base we've got today. But I don't want > to be told we need to switch to a new, alpha container, and wait for the > talk-fest to be over. Hey man, look: how can avalon force its users to do something, even if it wanted to? we want to 'unify' this community, we don't want to fragment it any more than it already is. Cocoon and James are the most important Avalon users. They have very different requirements, yet very common ones. Is it possible to provide a migration path that allows Cocoon and James to be based on different profiles of the same container and yet being back compatible? I think it's possible. For sure, I'll be the first one against Avalon imposing back-incompatible changes without a nice migration path to its users. > Please don't force us to fork Phoenix internally (or somewhere else) to get > the features we need. (No, this isn't a threat, or even likely. But I'd vote > +1 if I *really* had to.) I'd hate to see us lose the support of Peter D, > Paul H, Eung Ju, Leo S and the other Phoenix devs, who have provided so much > support over time. Same here dude. Cocoon will write its own avalon implementation and maintain it internally, but this is the *very last* resort. > This is Open-Source, right? We do this for fun, a challenge, and to make the > world a better place. Let's not make it harder than it has to be. Oh, please, I'm not trying to make things harder for the fun of it. Why should I? I care about Avalon as a user as much as you do. And this is why I'm concerned about avalon community fragmentation. James and Cocoon are based software maintained by a fragmented community. the history of open source dynamics show that this is a very dangerous thing. signs of internal friction and cracks have already appeared. I want avalon to be surrounded by a united community that cares about the framework. Today it's hard to tell if people care about the framework more than they care about its implementations and this is bad. -- Stefano Mazzocchi -------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: