Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAJ9DK3xRuYUuBUBcPLS8B9+mEZ2d8Zb-W8GTYoBCz61ukJ0-oQ@mail.gmail.com>
References: 
 <CADHGh9UbjOcGXA0k+1xYDgbqcawSM-ecWo62LDetxppy-D8T-A@mail.gmail.com>
 <52A056F4.1060505@die-schneider.net>
 <CAA66TppDqqtYaddJDRfFhT6SNRcyZeVT72RvDV6nYB5iH90UzA@mail.gmail.com>
 <52A05E4B.9030401@die-schneider.net> <52A06622.2050204@nanthrax.net>
 <CAJ9DK3xRuYUuBUBcPLS8B9+mEZ2d8Zb-W8GTYoBCz61ukJ0-oQ@mail.gmail.com>
From: Guillaume Nodet <gnodet@apache.org>
Date: Thu, 5 Dec 2013 13:31:21 +0100
Message-ID: 
 <CAA66TpoPynRGmyv0U35VRtHeGXEZv7VDbqX9mjBxB3vegar86Q@mail.gmail.com>
Subject: Re: A Blueprint Free Karaf
To: dev <dev@karaf.apache.org>
Content-Type: multipart/alternative; boundary=089e0160c66031e5ea04ecc8b67f

--089e0160c66031e5ea04ecc8b67f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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.goodyear@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 tr=
y
> 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=E9 <jb@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 i=
n
> > 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=80
> >
> > 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 t=
he
> >> core of user applications.
> >> It is fully featured regarding web and persistence if you include othe=
r
> >> JavaEE stuff and also defines a standardized extension mechanism.
> >> CDI is also well known to JavaEE developers. So my point is/was that C=
DI
> >> 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 i=
s
> >> 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 <chris@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 li=
ke
> >>>> 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 OSG=
i.
> >>> 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 OSG=
i
> >>> 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 specif=
ic
> >>>>> 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] (ou=
t
> >>>>> 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 kara=
f
> >>>>> 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 als=
o
> >>>>> 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 Servi=
ce
> >>>>> (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=E9
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>

--089e0160c66031e5ea04ecc8b67f--