You might want to educate yourself on DS before dismissing it. david jencks
On Dec 6, 2013, at 2:05 PM, Łukasz Dywicki <l...@code-house.org> wrote: > Yes Joed, > You got the point I wanted to reflect. DS and SCR is still dependency which, > for sure, may be optional. Switching to poorer replacement from feature rich > blueprint will bring bigger cost than moving to plain osgi. For me it will > look like stopping in half of the way. > Most of us knows well core spec plus something about blueprint. Very few from > us knows anything more about SCR, except the fact, that it's exists. This > kind of change may decrese number of maintaners to these who already know > SCR. From drawbacks of another DI I may throw that it requires, if I'm not > wrong, additional bundle header which lists all components. Also integration > with maven bundle plugin seems missing. Ie for blueprint we get imports for > free and validation, because when this plugin fails to read XML prevents > build from passing. > > The idea of extender, shared earlier in this topic, which install necessary > features is very good. It might be used in similar way as deployers or > feature resolvers to preprocess bundles before installation to automatically > enable certain features. > > Łukasz Dywicki > -- > Code-House > http://code-house.org > > Dnia 6 gru 2013 o godz. 21:12 Johan Edstrom <seij...@gmail.com> napisał(a): > >> I think Łukasz meant - use pure Java/OSGi, i.e no >> deps on SCR / DS at all? >> >> >> On Dec 6, 2013, at 12:42 AM, Guillaume Nodet <gno...@apache.org> wrote: >> >>> 2013/12/5 Daniel Kulp <dk...@apache.org> >>> >>>> >>>> On Dec 5, 2013, at 11:03 AM, Achim Nierbeck <bcanh...@googlemail.com> >>>> wrote: >>>> >>>>> Hi Johan, >>>>> >>>>> I'm fully with you for the client side I wouldn't walk that path for a >>>>> Karaf without Blueprint. >>>>> I just have the feeling that especially for the minimal bundle it could >>>> be >>>>> really helpful to start without >>>>> blueprint. >>>>> @Dan regarding minimal and blueprint, yes though I think since we'd still >>>>> provide the blueprint feature it would be viable way of doing minimal >>>>> without blueprint but the user who still needs it >>>>> needs to depend on that blueprint feature. >>>> >>>> The issues is what to do about frameworks that need blueprint, but the >>>> user may not. The user may not even know that Blueprint is needed. >>>> Their app may be completely spring-dm based or something. However, if they >>>> depend on CXF, they would also need blueprint or CXF won’t work (CXF uses >>>> Blueprint in many places). (Yes, changing CXF to use DS or something is >>>> certainly a possible enhancement, anyone want to tackle that?) >>>> >>>> Right now, there isn’t a “blueprint” feature that CXF can depend on. We >>>> can add one for 3.1 or 4.0, but if CXF then depends on it, then it would no >>>> longer load into any 2.3.x Karaf without also doing a 2.3.x release. >>>> That’s mostly my point, removing something that is there by default in 2.3 >>>> or 3.0 WILL have user impact. It’s not a major one, but it is something >>>> that needs to be considered on how to manage it, particularly for >>>> frameworks that tend to try and keep a range of compatible Karaf versions >>>> supported. >>>> >>>> It could also be something like having a very small bundle listener or >>>> bundle install hook or something in the core that when a bundle is loaded >>>> (pre-resolve), if there is a "Bundle-Blueprint” manifest, it would >>>> automatically start the blueprint feature. Might have some timing quirks >>>> that would need to be worked out, but possibly doable. >>> Instead of using a bundle listener which would only be called after >>> installation, it may be easier to just improve the FeaturesService >>> implementation to automatically add those requirements at runtime. >>> In short, we could easily rewrite the FeaturesServiceImpl#resolve(Feature) >>> method and hack what we need there: look at bundles and if they have a >>> blueprint header, add all the blueprint bundles. This would be more robust >>> than relying on a different bundle to kick in imho. >>> In the same area, we could also get rid of the OBR resolver and build a new >>> one using the real OSGi resolver, but that's a separate discussion I think. >>> >>> >>> >>> >>> >>>> Dan >>>> >>>> >>>> >>>>> >>>>> regards, Achim >>>>> >>>>> >>>>> 2013/12/5 Johan Edstrom <seij...@gmail.com> >>>>> >>>>>> 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 >>>>> >>>>> >>>>> -- >>>>> >>>>> 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/> >>>> >>>> -- >>>> Daniel Kulp >>>> dk...@apache.org - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>
