Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 84966B445 for ; Wed, 18 Jan 2012 11:54:01 +0000 (UTC) Received: (qmail 77804 invoked by uid 500); 18 Jan 2012 11:54:01 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 77707 invoked by uid 500); 18 Jan 2012 11:54:00 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 77699 invoked by uid 99); 18 Jan 2012 11:54:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jan 2012 11:54:00 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [69.167.147.50] (HELO franklin.liquidweb.com) (69.167.147.50) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jan 2012 11:53:55 +0000 Received: from localhost ([127.0.0.1]:55772) by franklin.liquidweb.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RnU57-0005OV-Dl for flex-dev@incubator.apache.org; Wed, 18 Jan 2012 06:53:33 -0500 Received: from 66.153.67.85 ([66.153.67.85]) by www.teotigraphix.com (Horde Framework) with HTTP; Wed, 18 Jan 2012 06:53:33 -0500 Message-ID: <20120118065333.19422qnvek2l1cjh@www.teotigraphix.com> Date: Wed, 18 Jan 2012 06:53:33 -0500 From: Michael Schmalle To: flex-dev@incubator.apache.org Subject: Re: OSGi bundle Plugin registry system References: <20120118063537.159124i231jed0nd@www.teotigraphix.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - franklin.liquidweb.com X-AntiAbuse: Original Domain - incubator.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - teotigraphix.com X-Source: X-Source-Args: X-Source-Dir: Outside obviously. :) I think I can see the future and Apache Flex needs multiple sub trunks IE sub projects. If you think about the amount of wasted momentum Flex has had over the last 4 years with code here, there and everywhere. Apache Flex needs to say our core value is consolidating code that can be used by many and we support that. GIT is fine for independent projects but I think if there is enough interest in the community for something that will enhance the flex SDK we need to figure out a way to consolidate these projects under our project. Doing this will only exponentially increase the traction of all our efforts. If this doesn't happen, Apache Flex than does what Adobe did, community last SDK first. Were not talking about an application framework here, its a runtime component framework that application frameworks can expose and use. Mike PS I'm happy just using this stuff in my projects as well, I'm just interested in the communities definitions right now. By no means is the way I did it the "right way" but, I do know the power of this pattern and it hasn't been exposed in Flex which is a shame. Quoting Roland Zwaga : > Hey there, > > I think such as system could be really interesting, because the development > patterns it exposes are pretty widely used. At the same time, > I'm not sure if it should be part of the SDK, or perhaps rather more as an > extension of the SDK. > It'll be a good discussion to determine what exactly people see as the > scope for the SDK, what type of functionality belongs in it, and what not. > An OSGi type of system as you describe is a really good example of such > functionality. In or out? > > thoughts? > > Roland > > On 18 January 2012 12:35, Michael Schmalle wrote: > >> Hi, >> >> I noticed in a thread a member talking about modules and loading at >> runtime, using the term bundles. Anyone familiar with that term might think >> OSGi. >> >> He listed the link below and said wouldn't it be great if Adobe open >> sourced this and donated it to Apache Flex. >> >> http://blogs.adobe.com/**gravity/2011/09/09/**hellogravity-sample-** >> application/ >> >> Well, I have been working with a plugin registry system on my own for >> about 3 years now, that uses IoC, and extension registry like Eclipse with >> extension points and extensions. The asdoc editor was created with this >> very same framework. >> >> Currently I'm using SpringAS for the IoC but if there was interest, we >> could abstract out the IoC and leave it application dependent on the system >> the app is using at the time. >> >> I would really love to know if there was an interest in this type of >> project because I have so much time into one already. I have experimented >> as well with loading modules as bundles and it worked great using the >> Plugin paradigm. New extensions were loaded at runtime which would say >> allow new views and editors, commands etc. >> >> Truly if there was an area I would love to expose with Apache Flex is >> showing it's potential in creating this dynamic runtime component system. >> >> The base framework is located; >> >> https://github.com/**teotigraphix/sx-plugins >> >> The ui framework; >> >> https://github.com/**teotigraphix/sx-ui >> >> -> Menus, Toolbars, Dialogs, Windows >> >> Note; I have been updating these in the last month to abstract AIR deps >> out of the ui framework. The base framework still uses Spring 1.1. But as I >> said, if there was interest, we would abstract this to an IoC interface. >> >> Let me know, if now, I will still keep developing this for my won projects. >> >> Also, I now have it that you can run an app in the browser and desktop >> using the same code, creates different type shells based on the environment. >> >> Thanks, >> Mike >> >> >> >> >> >> >> > > > -- > regards, > Roland > > -- > Roland Zwaga > Senior Consultant | Stack & Heap BVBA > > +32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com >