David, I was using declarative services a bit so all my considerations are based on experiences I have got couple of years ago. If tools moved forward, that's fine, but please don't use a single sentence to discard whole email. I believe you have better arguments and you may bring links which will prove it. This will give an extra feedback for others who are tracking this topic.
Cheers :) Lukasz Wiadomość napisana przez David Jencks <david_jen...@yahoo.com> w dniu 7 gru 2013, o godz. 08:18: > 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 >>> >
