Basically that's the crux of the technical discussion -- is this change user land breaking, hence requiring more than a minor version, and secondly from a support point of view - would having such a change between minor versions present a large challenge for back porting fixes between the two lines. If the answer is yes to the above then i'd move towards a major version, if the answer is no then we may be able to go minor.
Are there other concerns out there that we need to consider from a versioning point of view? --Jamie On Thu, Dec 5, 2013 at 9:01 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. > > > 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 > > > > > >
