Hi Trustin, On Fri, 2006-09-01 at 12:17 +0900, Trustin Lee wrote:
> Cool. I really appreciate your will! One question: where would these maven > projects should be located? > I think the MINA OSGi bundles should be > splitted into multiple bundles as we did for MINA JARs (mina-core, > mina-filter-ssl, ...). If so, placing these directories directly under > trunks/mina will not look really good. Here's my suggestion for the > directory structure: > > trunks/mina > - core > - filter-ssl > - filter-codec-asn1 > - filter-codec-netty2 > - integration-spring > - integration-osgi > ---- core (OSGi bundle for core) > ---- filter-codec-asn1 (OSGi bundle for filter-codec-asn1) > ... > > Of course, we wouldn't need this hierarchy if maven-osgi-plugin can generate > multiple buldles with one project. > > WDYT? Initially we can just add the osgi plugin specifications to the existing projects' pom.xml files and not create any new projects. Adding the plugin specifications will create the necessary metadata in the jar when it is built allowing the jar to also act as an OSGi bundle. In other words the jar still acts like it did before - for any non-osgi application, but it also works as an OSGi bundle. (Sort of like Clark Kent and Superman. Clark still goes to work at the Daily Planet:) For the first Mina OSGi effort I suggest offering Mina packages and classes to other bundles in the OSGi framework - in other words Mina at first will be a set of OSGi library bundles. This is relatively easy. Have already done this for the Mina core project by adding the OSGi plugin specs to the core project ( will soon post a patch to Jira) pom.xml. Will begin filter-ssl, filter-codec-asn1, and filter-codec- netty2 today. Once done Mina becomes a first class OSGi citizen. (Good bye wrapper projects.) The sexy stuff can come latter - Dynamic OSGi configuration of Mina will require something more than just offering libraries to clients. Dynamic configuration will require Mina support for OSGi Configuration Admin support and possibly Initial Provision service support in order to offer on-the-fly creation of servers from metadata stored in a standard OSGi configuration repositories. (Of course for us this means the ADS!) To answer your original question I think Mina projects may end up looking like very much like they do today. With the possible addition of an osgi-configuration project and maybe an osgi-agent project. trunks/mina - core - filter-ssl - filter-codec-asn1 - filter-codec-netty2 - integration-spring - osgi-configuration ? - osgi-agent ? To imagine this more objectively I will need to better understand how Spring is being used today for Mina application creation and configuration. Trustin, I have seen the JavaDocs for the Spring integration, but can you direct me to any document describing the overall requirements that you have for how Spring is used to configure Mina applications? Or if that is lacking can you share with me a set of Spring xml docs to show me a variety of configuration scenarios? cheers, John
