Return-Path: Delivered-To: apmail-incubator-general-archive@www.apache.org Received: (qmail 8602 invoked from network); 1 Sep 2009 20:21:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Sep 2009 20:21:00 -0000 Received: (qmail 16415 invoked by uid 500); 1 Sep 2009 20:21:00 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 16232 invoked by uid 500); 1 Sep 2009 20:20:59 -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 16221 invoked by uid 99); 1 Sep 2009 20:20:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 20:20:59 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [194.109.24.23] (HELO smtp-vbr3.xs4all.nl) (194.109.24.23) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2009 20:20:50 +0000 Received: from [10.0.0.10] (planetmarrs.xs4all.nl [82.95.193.148]) (authenticated bits=0) by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id n81KKQek069757 for ; Tue, 1 Sep 2009 22:20:26 +0200 (CEST) (envelope-from marcel.offermans@luminis.nl) From: Marcel Offermans Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/alternative; boundary=Apple-Mail-15-798802233 Subject: Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi Date: Tue, 1 Sep 2009 22:20:25 +0200 In-Reply-To: To: References: Message-Id: <26A1A7C9-DD38-41E7-9403-18302E626279@luminis.nl> X-Mailer: Apple Mail (2.1075.2) X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-15-798802233 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Sep 1, 2009, at 16:38 , Jeremy Hughes wrote: > It is a goal of the Aries project to provide a natural home for open > source implementations of current and future OSGi EEG specifications, > including the opportunity for the collaborative development of > compliance tests, and an environment to demonstrate the composition of > these technologies and to explore areas where EEG specifications lack > coverage. A further goal of this project is to leverage experience > gained from it to inform contributions to OSGi EEG requirements and > specification documents. Just reading this paragraph my initial reaction is that this is very much aligned with the Felix project. Felix's goals are basically to provide a full OSGi implementation of both the framework and compendium services whilst also providing a home for extensions to the specification that make sense. In that sense Aries sounds like a subset of Felix's goal, targetting the enterprise specifications. > The Aries project will deliver run-time componentry that supports > applications [...] The project is not expected to deliver a complete > application or > integration server runtime but will instead deliver enterprise > application componentry that can be integrated into such runtimes. This makes a lot of sense. Any project building on a component architecture should be setup in such a way that many of the individual components can be combined and reused in different deployment scenarios. > There is currently no Apache project focussed > on OSGi enterprise applications that is independent from both the OSGi > framework This is a really interesting topic, and others have commented on this: the perception that bundles in the Felix project only run on Felix. Of course anybody who makes an effort to understand OSGi quickly learns that the whole purpose of the spec is to have bundles that can run on any implementation and from years of experience of doing OSGi projects, I must say that every project I did, did in fact use bundles from Felix, Knopflerfish, Eclipse, Pax, various other sources as well as project specific bundles. My view is that we should really try to fix this misconception instead of using it as a reason to start new projects. > For this reason we believe > Aries is a project whose community would be best served if it could > leverage but be independent from the communities that provide > underlying OSGi framework technology If you look at the OSGi specification as a whole, it consists of two parts: the framework and the compendium. In fact, with the different expert groups, you could say there is more than one compendium as each expert group usually adds a compendium of their own. Anyway, OSGi is more than just the framework alone, and Felix already supplies an implementation of the whole spec, so there currently is no community that provide just the OSGi framework (also look at Knopflerfish and Equinox, both of which also provide compendium implementations). > Relationships with Other Apache Projects I know ACE is only in incubation, but is there a reason for not mentioning it in this list? To me it makes sense to also consider technology to deploy and update OSGi components and I think ACE could fit in there nicely. > The incubator. Successful graduation from Incubator should result in > Aries becoming a new TLP. As others mentioned, this is perhaps an issue that should be addressed when leaving the incubator. As I explained above, my personal view is that this would fit nicely within the Felix TLP, especially since there seems to be a lot of focus on implementing the OSGi Enterprise "compendium" which is part of the OSGi specifications. On the other hand, if you guys really want to work outside of Felix then of course that's an option too. I do think it's great that there is a group of people wanting to implement these enterprise specs and explore related options! Let's just try and leverage each others' work as much as possible! Greetings, Marcel --Apple-Mail-15-798802233--