karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: A Blueprint Free Karaf
Date Thu, 05 Dec 2013 16:03:26 GMT
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.

regards, Achim


2013/12/5 Johan Edstrom <seijoed@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é <jb@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é <jb@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 <gnodet@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.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
> >>>>>> 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é <
> 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
> >>>>>>> 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 <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
> >>>>>>>>>> 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é
> >>>>>>> jbonofre@apache.org
> >>>>>>> http://blog.nanthrax.net
> >>>>>>> Talend - http://www.talend.com
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>> --
> >>> Jean-Baptiste Onofré
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>
> >>
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@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/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message