Looking out there, I've seen one customer using DS in the last 3 years or so. TX, JPA, Spring migrations, Spring only, BP only - sure. Not to mention NS Handlers and so on.
It would make a "tiny" karaf viable, less deps and faster startup. I doubt any developing user would (want to) be able to give up DI. /je On Dec 5, 2013, at 8:36 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > You are right, but we should be careful about the side effects, overlap, etc > ;) > > On 12/05/2013 04:32 PM, Achim Nierbeck wrote: >> 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 >>> >> >> >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
