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
