Return-Path: Delivered-To: apmail-incubator-general-archive@www.apache.org Received: (qmail 67132 invoked from network); 4 Sep 2009 13:53:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Sep 2009 13:53:53 -0000 Received: (qmail 23641 invoked by uid 500); 4 Sep 2009 13:53:52 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 23436 invoked by uid 500); 4 Sep 2009 13:53:52 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 23426 invoked by uid 99); 4 Sep 2009 13:53:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Sep 2009 13:53:52 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [216.40.44.230] (HELO smtprelay.hostedemail.com) (216.40.44.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Sep 2009 13:53:41 +0000 Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id 15A1E15DAA81 for ; Fri, 4 Sep 2009 13:53:20 +0000 (UTC) X-Spam-Summary: 50,0,0,f9c6d3652c8da382,907452bc8cfe1759,dkulp@apache.org,general@incubator.apache.org:gcharters@googlemail.com,RULES_HIT:2:69:355:379:599:601:800:945:960:967:973:980:988:989:1260:1277:1311:1313:1314:1345:1358:1359:1437:1515:1516:1518:1535:1593:1594:1605:1730:1747:1766:1792:2194:2199:2379:2393:2525:2552:2553:2561:2564:2682:2685:2687:2691:2692:2693:2828:2857:2859:2898:2900:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3280:3865:3866:3867:3868:3869:3870:3871:3872:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4119:4250:4470:5007:6114:6119:6261:7514:7679:7860:7875:7903:8501:8985:9025:9108:9388,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fu,MSBL:none,DNSBL:none X-Session-Marker: 64616E406B756C702E636F6D X-Filterd-Recvd-Size: 8249 Received: from server.dankulp.com (server1.dankulp.com [66.207.172.168]) (Authenticated sender: dan@kulp.com) by omf08.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Sep 2009 13:53:19 +0000 (UTC) Received: by server.dankulp.com (Postfix, from userid 5000) id 066AC507046D; Fri, 4 Sep 2009 09:53:19 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.1-gr1 (2007-05-02) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter.3A38udnArW Received: from dilbert.localnet (c-24-91-141-225.hsd1.ma.comcast.net [24.91.141.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTPSA id C7795507045F; Fri, 4 Sep 2009 09:53:17 -0400 (EDT) From: Daniel Kulp To: general@incubator.apache.org Subject: Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi Date: Fri, 4 Sep 2009 09:53:12 -0400 User-Agent: KMail/1.12.1 (Linux/2.6.30-gentoo-r6; KDE/4.3.1; x86_64; ; ) Cc: Graham Charters References: <200909040905.42003.dkulp@apache.org> <345578340909040627o4039f224j4f4558b93734bfcd@mail.gmail.com> In-Reply-To: <345578340909040627o4039f224j4f4558b93734bfcd@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909040953.12989.dkulp@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-3.3 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1-gr1 On Fri September 4 2009 9:27:23 am Graham Charters wrote: > Having read all the discussions, I still have concerns about the > suggestion to put all OSGi spec implementation under Felix. I don't > see this approach being taken for other specification organizations > (JCP, OASIS, etc.) and I think that is to the benefit of Apache. For > example, whilst a goal of Geronimo is JEE compliance it does not host > all the implementations of the JEE specifications. Having OpenEJB, > OpenJPA, Tomcat, etc as separate projects allows them to evolve > independent communities, with cross-pollination. The domains, > technologies and skills required to cover the entirety of JEE are > diverse and the same is true for OSGi. To put these under one project > would lead to sub-groups of different interests under one disjoint > umbrella community. +1 Geronimo is a perfect example. Couldn't have said it better myself. The community of the "experts" in the technology area should be the ones implementing those specs as part of their community. Dan > > I also worry about the practicalities of saying that all OSGi spec > implementations belong in Felix. This is a moving target, both within > each specification, where extensions may be created and then > standardized and also at the spec level, where new concepts are > created and then standardized. Must these then move under the Felix > umbrella, which will undoubtedly create a lot of churn for users of, > and contributors to, Aries? > > Thinking about the problem the way JEE is handled makes me wonder if > Felix could pull in spec implementations from Aries (and have > committers on Aries) and therefore still contribute to and provide the > distribution of the entire OSGi Service Platform. Maybe this could be > done through Felix hosting a bundle repository (Felix commons?)? > Consumers of Felix would be able to get the OSGi Service Platform and > consumers of Aries would get the enterprise OSGi application portions. > > I'd like to emphasize that the desire to be separate from Felix is in > no way a criticism of that project. I have a huge amount of respect > for what Richard et al continue to achieve and having experienced > first-hand the value the combination of Felix and Equinox bring to the > OSGi standards, I sincerely believe that OSGi is far stronger as a > result. > > The desire to remain separate is based purely on the belief that this > is the approach which will best serve the goals of evolving an > enterprise OSGi application programming model, and a community around > its definition. This rationale is also the reason why Geronimo was > not suggested (an equally valid choice given the majority of the > Enterprise OSGi specifications leverage JEE technologies). I guess > what I don't understand is why the Incubator would not prove or > disprove this belief, without making a prior decision? > > Regards, Graham. > > 2009/9/4 Daniel Kulp : > > As a point of note, not all OSGi spec implementations live in Felix even > > at Apache today. The Remote Services/Distributed OSGi reference > > implementation is a sub project of CXF. I think Tuscany has an > > implementation as well. > > > > So far, there hasn't been any discussion about moving those into Felix. > > Your argument below makes it sound like they should be. > > > > Dan > > > > On Thu September 3 2009 1:33:04 pm Richard S. Hall wrote: > >> There was no attempt to contact the Felix PMC in general that I am aware > >> and I certainly didn't know about it in advance. > >> > >> And there seems to be a continued attempt to construe my original > >> criticisms as "all of Aries should go into Felix". > >> > >> I, personally, do not believe that all of Aries should go into Felix, I > >> too think it should have its own identity. I was always only ever > >> referring to the independent OSGi spec implementations. I was arguing > >> that Felix is a good place to work on them, since it is part of what it > >> is trying to achieve. > >> > >> Further, I don't really understand the implication that somehow the > >> burden is now on the Felix community to go and contribute to Aries on > >> OSGi spec implementations just because of this proposal, when there was > >> no attempt to work with the Felix community on creating OSGi spec > >> implementations in the first. > >> > >> The only conclusions I see being drawn by people who have invested very > >> little in Felix is that we should dismantle the Felix charter so that we > >> can accommodate the fact that some people don't want to play with us. > >> > >> At that rate, I stand by my previous "vote" and otherwise people can do > >> whatever they want in Aries. > >> > >> -> richard > >> > >> On 9/3/09 13:23, Niclas Hedhman wrote: > >> > Kevan, > >> > > >> > Was a contact with Felix made prior to dropping the proposal here? I > >> > got the impression that wasn't the case, which I find surprising... If > >> > I am wrong, what was the meat of such? > >> > > >> > I'm also less happy with the rhetoric here repeated over and over, > >> > seemingly uninterested in discussion of reaching a solution everyone > >> > can accept. (From both camps, btw) > >> > > >> > -- Niclas > >> > > >> > On Sep 4, 2009 12:53 AM, "Kevan Miller" > >> > wrote: > >> > > >> > On Sep 3, 2009, at 12:53 AM, Niclas Hedhman wrote:> On Thu, Sep 3, > >> > 2009 at 3:19 AM, William A. Ro... > >> > Totally agree. Had certainly hoped that Felix committers would be > >> > interested in joining... > >> > > >> > --kevan > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: gene... > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org > >> For additional commands, e-mail: general-help@incubator.apache.org > > > > -- > > Daniel Kulp > > dkulp@apache.org > > http://www.dankulp.com/blog > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org > > For additional commands, e-mail: general-help@incubator.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org > For additional commands, e-mail: general-help@incubator.apache.org > -- Daniel Kulp dkulp@apache.org http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org