Just wanted to contribute my 2 cents -- I'd look at a SCR Karaf for 4.0 - removing Blueprint dependencies from the core is too major a change to try to introduce it to 2.3.x or 3.0 at this stage.
--Jamie On Thu, Dec 5, 2013 at 8:10 AM, Jean-Baptiste Onofré <j...@nanthrax.net>wrote: > I think we have to distinguish different things: > - the learn curve and usage "outside" of Karaf for developers. CDI is like > EJB, and other framework. > - the usage of CDI "inside" an OSGi application or Karaf itself (or for > "native" OSGi applications). > > The fact that Karaf now supports CDI (via pax-cdi) is as good as > supporting OpenEJB (in KarafEE), or Spring (in Karaf "natively"). > > I would not use OpenEJB in Karaf "itself", nor Spring, nor CDI. > > If a developer wants to create a "generic" application (that can work in > both OSGi or non-OSGi containers), CDI is good. > If a developer want to create a native OSGi application, I would use > natively OSGi "specific" framework (like blueprint). > > My 0.02€ > > Regards > JB > > > On 12/05/2013 12:06 PM, Christian Schneider wrote: > >> Probably you are right. >> >> The reason why I came up with CDI is that it has the potential to be the >> core of user applications. >> It is fully featured regarding web and persistence if you include other >> JavaEE stuff and also defines a standardized extension mechanism. >> CDI is also well known to JavaEE developers. So my point is/was that CDI >> may be the only thing a developer needs to learn regarding dependency >> injection. >> >> On the other hand a programmer of user applications running on karaf is >> quite decoupled from the karaf services and commands. >> So it is probably not necessary that he uses and understands the karaf >> internals. So from this perspective minimum footprint counts more than >> having only one framework. So from this point of view DS really is >> better than CDI. >> >> Another argument supporting this is that while I see most potential in >> CDI to take over dependency injection in user space it is far from the >> only solution. So there will always be people who use something else. As >> karaf needs to support a wide range of frameworks this also speaks for >> minimum footprint for karaf's internals. >> >> Christian >> >> On 05.12.2013 11:49, Guillaume Nodet wrote: >> >>> 2013/12/5 Christian Schneider <ch...@die-schneider.net> >>> >>> Good idea to look into alternatives to blueprint. >>>> >>>> The big advantage I see for DS is that it is very light weight. I am not >>>> so sure about its long term future though. >>>> I personally think the future of OSGi dependency injection is CDI like >>>> pax-cdi + weld or openwebbeans. >>>> Of course this is not really near term and far from being a sure bet. >>>> Still I think if we switch the DI framework we should >>>> also at least experiment with CDI. I am currently working on a karaf >>>> tutorial for CDI. The service injections already work very well. >>>> I am now looking into jpa support. >>>> >>>> I disagree. CDI will have the same problems as blueprint, it's an >>> application level injection framework, not focused *primarily* on OSGi. >>> The lifecycle of CDI beans has to be static, so you have to use proxies. >>> Blueprint has the exact same problem where the beans lifecycle is >>> bound to >>> the lifecycle of the container. On the opposite, DS has a better >>> lifecycle mechanism for beans which can naturally handle the OSGi >>> dynamism. >>> >>> And CDI would be even more heavyweight than blueprint, so I'd rather >>> stick >>> with blueprint than switching to CDI, even if it were ready. >>> The real benefit of DS is that it has been designed to handle the OSGi >>> dynamism, so it does less, but it does it better. >>> >>> >>> In any case I think switching the DI framework should be considered for >>>> karaf 4. So in this case we have a bit of time to experiment. >>>> >>>> Christian >>>> >>>> >>>> On 04.12.2013 21:41, Ioannis Canellos wrote: >>>> >>>> For anyone curious on how Karaf without Blueprint would look like, >>>>> here is a karaf branch that is free of blueprint: >>>>> https://github.com/iocanel/karaf/tree/karaf-light (it's a fork of the >>>>> karat-2.3.x branch). >>>>> >>>>> It is actually a refactored karaf 2.3.x that removes blueprint from >>>>> all modules (yet still provides blueprint as feaures). Karaf specific >>>>> blueprint namespace handlers have moved to optional bundles so that >>>>> they can still be used if needed. >>>>> Blueprint has been replaced with Felix SCR (including the shell >>>>> commands). Moreover, misc refactorings on features and startup bundles >>>>> have been performed in order to reduce the size and the amount of >>>>> bundles in the minimal distro. >>>>> >>>>> The result is a minimal distribution that starts 12 bundles [1] (out >>>>> of 37 which were part of karaf 2.3.3 minimal distro). 10 of those >>>>> bundle were blueprint bundles and the rest are extra noise. >>>>> >>>>> My motivation behind this refactoring was: >>>>> i) I like declarative services more than blueprint. >>>>> ii) I've been working on projects that are packaged inside the karaf >>>>> minimal distro which would benefit from a smaller size (e.g. >>>>> jclouds-cli). >>>>> iii) I wanted to make a karaf distro as flexible as possible. >>>>> >>>>> Please note that my main focus was the minimal distribution and also >>>>> this is not 100% polished. >>>>> >>>>> Enjoy! >>>>> >>>>> >>>>> [1]: The bundle list of the minimal distro: >>>>> >>>>> ID State Level Name >>>>> [ 0] [Active ] [ 0] System Bundle (4.0.3) >>>>> [ 1] [Active ] [ 5] OPS4J Pax Url - mvn: (1.3.6) >>>>> [ 2] [Active ] [ 5] OPS4J Pax Url - wrap: (1.3.6) >>>>> [ 3] [Active ] [ 8] OPS4J Pax Logging - API (1.7.1) >>>>> [ 4] [Active ] [ 8] OPS4J Pax Logging - Service (1.7.1) >>>>> [ 5] [Active ] [ 10] Apache Felix Configuration Admin Service >>>>> (1.6.0) >>>>> [ 6] [Active ] [ 11] Apache Felix File Install (3.2.6) >>>>> [ 7] [Active ] [ 13] Apache Felix Declarative Services (1.6.2) >>>>> [ 8] [Active ] [ 25] Apache Karaf :: Shell :: Console >>>>> (2.3.4.SNAPSHOT) >>>>> [ 9] [Active ] [ 30] Apache Karaf :: Features :: Core >>>>> (2.3.4.SNAPSHOT) >>>>> [ 10] [Active ] [ 30] Apache Karaf :: Features :: Command >>>>> (2.3.4.SNAPSHOT) >>>>> [ 11] [Active ] [ 30] Apache Karaf :: Shell :: Log Commands >>>>> (2.3.4.SNAPSHOT) >>>>> [ 12] [Active ] [ 30] Apache Karaf :: Shell :: OSGi Commands >>>>> (2.3.4.SNAPSHOT) >>>>> >>>>> >>>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Open Source Architect >>>> http://www.talend.com >>>> >>>> >>>> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
