Return-Path: Delivered-To: apmail-avalon-dev-archive@avalon.apache.org Received: (qmail 64679 invoked by uid 500); 9 May 2003 18:55:34 -0000 Mailing-List: contact dev-help@avalon.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 dev@avalon.apache.org Received: (qmail 64623 invoked from network); 9 May 2003 18:55:33 -0000 Received: from onramp.i95.net (205.177.132.17) by daedalus.apache.org with SMTP; 9 May 2003 18:55:33 -0000 Received: from apache.org ([66.208.12.130]) by onramp.i95.net (8.12.9/8.12.9) with ESMTP id h49Itb07026182 for ; Fri, 9 May 2003 14:55:37 -0400 Message-ID: <3EBBF9E7.6060902@apache.org> Date: Fri, 09 May 2003 14:56:39 -0400 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: Re: [RT] Avalon Bundles/Distribution Units References: <3EBBC557.7040305@apache.org> <3EBBF325.80806@apache.org> In-Reply-To: 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 Leo Simons wrote: > just playing devil's advocate some more..... > > Berin Loritsch wrote: > >>> why not just use .Net? > > > > [we don't know how to program .Net yet; there is no free version of > .Net, there is no free .Net support for java; many (free) tools which > exist for java do not exist for .Net; we might do better than .Net by > taking concepts from other places as well; in conclusion there is a need > for a native-java version of this stuff] > > fair enough :D. We should just keep in mind that most of these reasons > will likely no longer exist in a few years time. That might affect some > decisions :D We can get this done, or at least workable, in less than "a few year's time". That is an important consideration. The good thing about doing it is it makes it easier to apply the same principles in new languages that haven't even been invented with. [Spoiler: I am toying with the idea of writing my own language. Nothing concrete yet, though.] > >> One question that also begs to be asked is if this is something that is >> generic enough to develop in Jakarta Commons, and extend it here. > > > well, yes. OTOH, everything in avalon-framework besides the actual > XXXble lifecycle interfaces and ServiceManager is generic enough for > that as well (ie CascadingException, Context, Configuration, > SAXConfigurationBuilder). Where's the potential community for this stuff > at? It is here right now. > > Answering this question is trying to strike the balance between doing an > all-encompassing bloatware and an extremely fragmentized > doesn't-do-anything 5-levels of abstraction dependency-fragile > metametametalayer. You never get it perfectly right :D :) I am almost positive that there will be more support for distributable management than for the Avalon classes that despite their usefulness in other contexts will forever be bound here. Also, I agree that we need to strike a balance. I don't want any fragile solutions. I want to keep the dependency list for the bundle API at a minimum. We need something that works, and works well. -- "You know the world is going crazy when the best rapper is a white guy, the best golfer is a black guy, The Swiss hold the America's Cup, France is accusing the US of arrogance, and Germany doesn't want to go to war. And the 3 most powerful men in America are named 'Bush', 'Dick', and 'Colon' (sic)". -----Chris Rock --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For additional commands, e-mail: dev-help@avalon.apache.org