As far as I understood the idea, it's to use DS for Karaf itself, not to get rid of Blueprint. Just so Karaf itself does have a smaller footprint. @Ioannis did I get this right?
regards, Achim 2013/12/5 Jean-Baptiste Onofré <j...@nanthrax.net> > Good point Dan. > > I think you should not hurry about this. > > Ioannis did a good PoC, but I quickly discussed with him and his goal is > not to "force" the inclusion on Karaf 3.x. > > I think it makes more sense (and it's wise ;)), to act for a plan for > Karaf 4.x. > > Regards > JB > > > On 12/05/2013 04:26 PM, Daniel Kulp wrote: > >> >> On Dec 5, 2013, at 7:31 AM, Guillaume Nodet <gno...@apache.org> wrote: >> >> I think that can be argued : it's a big internal change, but not really a >>> user-facing one. If the work is done in a compatible way (which I think >>> is >>> doable and should be the goal), it can be done in a minor release, as it >>> would be almost transparent for the user: i.e. a user should still be >>> able >>> to deploy his own application without any changes. So I don't think it >>> requires a major version change. >>> >> >> Well, there COULD be an impact…. Right now, some of the features.xml >> files out there just assume blueprint is available. For example, CXF’s >> just assumes blueprint is there. They don’t depend on any “blueprint” >> feature. Thus, an application (or CXF) that would deploy fine on the >> minimal container out of the box right now would not with 3.1 (or whatever) >> where blueprint isn’t there. >> >> We COULD adjust for this by adding a “blueprint” feature right now >> (before 3.0 ships) that is relatively redundant with the “framework” >> feature (or have framework depend on the new blueprint) that the other >> features.xml could start depending on. That could also be added for a >> 2.3.x patch as well. >> >> >> >> Dan >> >> >> >> 2013/12/5 Jamie G. <jamie.goody...@gmail.com> >>> >>> 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 >>>>> >>>>> >>>> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
