[jboss-dev-forums] [Design of OSGi Integration] - New project structure

In order to support more than just our own OSGi impl, we decided to re-factor current project structure. We'll be adding new "Runtime" module to the project, and since some of the work overlaps, this calls for a structure revamp. :-) I'll explain what is the "purpose" of each of the nodes in the structure. * JBoss OSGi ** Repository *** API (OBR API) *** Impl (possible ORB API impl); we should take some existing ** Our OSGi impl - we need a _real_ project name, any suggestion welcome ;-) *** Boot (minimal boot); re-using new JBoss Boostrap split *** Deployers (custom deployers) *** Facade (core OSGi API impl) ** Runtime (plugable platform for various OSGi frameworks, including our) *** SPI (framework abstraction) *** Deployers (custom deployers) *** "Our impl" integration *** Felix integration *** Equinox integration (optional) *** Knopflerfish integration (optional) ** Services (glue code, no real impl) *** Console (integration work/patch to re-use existing) *** HttpService (integration work/patch to re-use existing) ** Common (shared code between "Our impl" and Runtime) *** MetaData *** Deployers The effort of having "Runtime" is to provide initial testing ground for TCK. Once we pick up the pace with "Our Impl", we'll put minimal effort into "Runtime". It should be then mostly demand driven. "Services" module holds the pieces that glue/integrate "Runtime" with JBossAS due to missing architecture. e.g. Embedded Tomcat/JBossWeb or decent Console Once we have "Our impl", the console work should really be just a matter of exposing services via Managed/Metatype project and possibly embedded/standalone ProfileService. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212915#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...