You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Ioannis Canellos <io...@gmail.com> on 2013/12/04 21:41:41 UTC
A Blueprint Free Karaf
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)
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: A Blueprint Free Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Agree with Guillaume. I don't see value to CDI comparing to Blueprint.
Regards
JB
On 12/05/2013 11:49 AM, 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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: A Blueprint Free Karaf
Posted by Hadrian Zbarcea <hz...@gmail.com>.
+1 (agree w/ Guillaume)
Hadrian
On 12/05/2013 07:31 AM, Guillaume Nodet 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. <ja...@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 <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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>
Re: A Blueprint Free Karaf
Posted by Daniel Kulp <dk...@apache.org>.
On Dec 5, 2013, at 10:32 AM, Achim Nierbeck <bc...@googlemail.com> 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?
Yea, I’m 100% OK with that. I’m just saying if we take it that one step further and remove the blueprint (that would no longer be needed) from the minimal distributions, that will have an impact on users. So basically, I think I’m OK with the code changes and such to flip to DS, just not quite so OK with the removal of BP by default (even if it’s not used by karaf).
Dan
>
> 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 <gn...@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. <ja...@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 <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é
>>>>>> 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/>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: A Blueprint Free Karaf
Posted by Hadrian Zbarcea <hz...@gmail.com>.
What I like about this is the *minimal* part. I've built rpm and deb
packages one could use to easily install karaf on linux with yum or
apt-get (still a bit of work left to be fully workable). It has less to
do with the OSGi functionality and more with deployment and operation
related aspects. Once you have the container up and running the rest can
be installed directly from karaf. The impact @dkulp mentioned is
certainly there, but I would prefer it to be addressed in a different
way than making the minimal less minimal.
From the peanut gallery,
Hadrian
On 12/05/2013 11:36 AM, Ioannis Canellos wrote:
> Well, when I started that POC, I wasn't targeting any future release
> of Karaf, as I was not sure if people will like it anyway.
>
> I don't want to stall Karaf 3.0.0, that's true. But if we can prepare
> the ground and finally add this in a Karaf 3.x (as Dan suggested) it
> would be a HUGE win for everyone. Mostly, because we will be able to
> ship it without rushing a Karaf 4.x which would mean extra overhead in
> maintaining multiple major version (especially when we can hardly
> managed 2.x and 3.x).
>
> @Achim: The original idea was to replace blueprint with scr and make
> blueprint optional for all distros (not installed by default, but
> being available as an option just like spring). The benefits:
>
> i) A better tool for the job.
> ii) Smaller footprint.
> iii) Freedom for the user to use the impl and version of blueprint of
> his choice.
>
> @Johan: By no means I'd like to limit the users options. But that
> doesn't mean that we should use the same things that the users will
> do. The users are building apps and they can pick the most fitting
> tool and we on the other hand are building a runtime and we need to
> pick the best tool for our job. It doesn't have to be the same tool.
>
>
Re: A Blueprint Free Karaf
Posted by Johan Edstrom <se...@gmail.com>.
Ioannis / Achim,
I think I was just stating the obvious for the sake of having it
stated :)
I agree that it would simplify the core of Karaf not to mention
that the commands and services don't really use DI.
On Dec 5, 2013, at 9:36 AM, Ioannis Canellos <io...@gmail.com> wrote:
> Well, when I started that POC, I wasn't targeting any future release
> of Karaf, as I was not sure if people will like it anyway.
>
> I don't want to stall Karaf 3.0.0, that's true. But if we can prepare
> the ground and finally add this in a Karaf 3.x (as Dan suggested) it
> would be a HUGE win for everyone. Mostly, because we will be able to
> ship it without rushing a Karaf 4.x which would mean extra overhead in
> maintaining multiple major version (especially when we can hardly
> managed 2.x and 3.x).
>
> @Achim: The original idea was to replace blueprint with scr and make
> blueprint optional for all distros (not installed by default, but
> being available as an option just like spring). The benefits:
>
> i) A better tool for the job.
> ii) Smaller footprint.
> iii) Freedom for the user to use the impl and version of blueprint of
> his choice.
>
> @Johan: By no means I'd like to limit the users options. But that
> doesn't mean that we should use the same things that the users will
> do. The users are building apps and they can pick the most fitting
> tool and we on the other hand are building a runtime and we need to
> pick the best tool for our job. It doesn't have to be the same tool.
>
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel
Re: A Blueprint Free Karaf
Posted by Ioannis Canellos <io...@gmail.com>.
Well, when I started that POC, I wasn't targeting any future release
of Karaf, as I was not sure if people will like it anyway.
I don't want to stall Karaf 3.0.0, that's true. But if we can prepare
the ground and finally add this in a Karaf 3.x (as Dan suggested) it
would be a HUGE win for everyone. Mostly, because we will be able to
ship it without rushing a Karaf 4.x which would mean extra overhead in
maintaining multiple major version (especially when we can hardly
managed 2.x and 3.x).
@Achim: The original idea was to replace blueprint with scr and make
blueprint optional for all distros (not installed by default, but
being available as an option just like spring). The benefits:
i) A better tool for the job.
ii) Smaller footprint.
iii) Freedom for the user to use the impl and version of blueprint of
his choice.
@Johan: By no means I'd like to limit the users options. But that
doesn't mean that we should use the same things that the users will
do. The users are building apps and they can pick the most fitting
tool and we on the other hand are building a runtime and we need to
pick the best tool for our job. It doesn't have to be the same tool.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: A Blueprint Free Karaf
Posted by Łukasz Dywicki <lu...@code-house.org>.
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 <da...@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 <lu...@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 <se...@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 <gn...@apache.org> wrote:
>>>
>>>> 2013/12/5 Daniel Kulp <dk...@apache.org>
>>>>
>>>>>
>>>>> On Dec 5, 2013, at 11:03 AM, Achim Nierbeck <bc...@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 <se...@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 <gn...@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. <ja...@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 <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é
>>>>>>>>>>>>>> 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/>
>>>>>
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>> Talend Community Coder - http://coders.talend.com
>>>
>
Re: A Blueprint Free Karaf
Posted by David Jencks <da...@yahoo.com>.
You might want to educate yourself on DS before dismissing it.
david jencks
On Dec 6, 2013, at 2:05 PM, Łukasz Dywicki <lu...@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 <se...@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 <gn...@apache.org> wrote:
>>
>>> 2013/12/5 Daniel Kulp <dk...@apache.org>
>>>
>>>>
>>>> On Dec 5, 2013, at 11:03 AM, Achim Nierbeck <bc...@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 <se...@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 <gn...@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. <ja...@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 <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é
>>>>>>>>>>>>> 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/>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>
Re: A Blueprint Free Karaf
Posted by Guillaume Nodet <gn...@apache.org>.
2013/12/7 Łukasz Dywicki <lu...@code-house.org>
> Going directly to your quesstion
>
> My solution would be:
> - Create proxy factory which takes interface then, returned proxy should
> open service tracker and take care of tracking.
> - For configuration - simply use ManagedService, after all - that's what
> aries is doing - thing we get from it is property injection.
>
> There is no "pure" osgi code which will satisfy your needs. Simply by fact
> that you have different things which comes from different parts of spec,
> which are deatached from each other. Service registration have nothing to
> do with it's configuration. Now we are, let say, safe because aries masks
> that. It doesn't really mean that we'are not having souch issues as you had
> with pax-web. It's just handled by Aries, and even if Aries is very good,
> it sometimes just fails as every generic purpose tool. I don't push many
> contibutions to Karaf these days, however I heavily use it on daily basics,
> and I am hit by some problems (NullPointers in cm-blueprint internals,
> hangouts when using dev:watch, lack of initial update call when
> cm:managed-properties are used). Fact that we don't see threading issues
> with Aries doesn't really mean it doesn't have it. If you close eyes, world
> still exists. This is proven. :-)
>
What I meant by pure, is just not reusing an existing framework to help
with the work, i.e. going straight to the OSGi Framework and CM apis. I
don't say there are no issues in Aries, quite the opposite. What I really
want to express is the fact that writing robust code in OSGi is *really*
difficult. So it just does not make any sense to me to try multiplicating
such code instead of reusing a good framework which does that for us,
whatever it is.
>
> Here, going into detail - Aries in our use case in 90% is limited to
> startup time. So if the service we would like to publish depens on two
> mandatory references we just should hold registration untill dependencies
> are satisfied. We know what dependencies are, proxy factory keeps eye on it
> so we'll catch moment when everything pops in. Just by counting open/close
> calls we will be able to call registration callback. We can at least try
> doing that. In theory, if we'll solve most complicated use case, we now
> have in Karaf, other things should raise smaller issues.
>
As I said, when I wrote "pure", I meant without Aries, DS or any framework,
which is what you're proposing if I understood correctly. I'm not talking
about something that works, but something which is robust, i.e. thread safe
and not opened to deadlocks. If you are willing to go into more details,
we can try to write such a small thing and see the resulting complexity of
the code.
> On configuration side - declarative services are all about services, so
> we'll need to register ManagedService instance anyway and handle updaes on
> our own.
>
>
Fwiw, DS manages configuration too (not to the level of blueprint, it's
mostly a bulk update), so you have no need to implement a ManagedService
directly.
> Cheers,
> Łukasz Dywicki
> --
> luke@code-house.org
> Twitter: ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
> Wiadomość napisana przez Guillaume Nodet <gn...@apache.org> w dniu 7 gru
> 2013, o godz. 16:15:
>
> > I don't count the number of weeks I've spent during the last months
> fixing
> > pure OSGi code for concurrency and thread safety issues. And that
> includes
> > Karaf, Pax-Web, Blueprint, Fabric and even SCR. Service trackers are
> nice
> > tools, but not sufficient at all when it comes to handle multiple service
> > dependencies along with configuration changes.
> > Of course, registering commands is quite easy whatever method we use
> (pure
> > OSGi, DS, blueprint or any other tool).
> >
> > Let's consider a simple use case: a bundle which expose an OSGi service
> > which has 2 service dependencies and a configuration. Can you show me a
> > pure OSGi code that does it in a safe way ?
> >
> > Guillaume
> >
> >
> > 2013/12/7 Łukasz Dywicki <lu...@code-house.org>
> >
> >> All pax libraries we have deployed in Karaf are written without any
> piece
> >> of injection frameworks. Starting from pax logging over pax web, to pax
> >> wicket even (it supports blueprint namespaces but does not use it for
> >> service tracking).
> >>
> >> On other hand, does registration of commands is so hard that could not
> be
> >> done from Activator code? I don't think so. Most critical place which
> will
> >> be affected is actually a tracker, which will need to be registered by
> us.
> >> Indeed we'll get more code to maintain, but that's just matter of good
> >> modularization to keep it clean. Honestly, most of complications we
> have is
> >> hiden in service implementations. That's why I do consider dropping of
> >> dependency injection framework. It is something which can be done, it's
> >> just matter of balance between cons and pros.
> >>
> >> Best regards,
> >> Łukasz Dywicki
> >> --
> >> luke@code-house.org
> >> Twitter: ldywicki
> >> Blog: http://dywicki.pl
> >> Code-House - http://code-house.org
> >>
> >> Wiadomość napisana przez Christian Schneider <ch...@die-schneider.net>
> w
> >> dniu 7 gru 2013, o godz. 13:14:
> >>
> >>> I went the pure OSGi way for CXF DOSGi. It works but is quite error
> >> prone as you have to handle the dynamics of services and config
> yourself.
> >> As DOSGi is a pretty small project I think it was worth the effort for
> >> getting rid of DI dependencies.
> >>>
> >>> For karaf I would not like to have to do this for every service and
> >> command bundle. DS might work quite well there.
> >>> I have looked into the source from Ioannis. He uses SCR annotations for
> >> the wiring and the felix scr plugin to generate the xml. So it looks
> like
> >> not to much effort. The learning curve is of course there but I think
> with
> >> some good example projects it should be relatively easy.
> >>>
> >>> I have not yet seen how the SCR annotations handle config injection. I
> >> hope it works equally well.
> >>>
> >>> Christian
> >>>
> >>>
> >>> Am 06.12.2013 23:05, schrieb Łukasz Dywicki:
> >>>> 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
> >>>>
> >>>
> >>> --
> >>> Christian Schneider
> >>> http://www.liquid-reality.de
> >>>
> >>> Open Source Architect
> >>> Talend Application Integration Division http://www.talend.com
> >>>
> >>
> >>
>
>
Re: A Blueprint Free Karaf
Posted by Łukasz Dywicki <lu...@code-house.org>.
Going directly to your quesstion
My solution would be:
- Create proxy factory which takes interface then, returned proxy should open service tracker and take care of tracking.
- For configuration - simply use ManagedService, after all - that's what aries is doing - thing we get from it is property injection.
There is no "pure" osgi code which will satisfy your needs. Simply by fact that you have different things which comes from different parts of spec, which are deatached from each other. Service registration have nothing to do with it's configuration. Now we are, let say, safe because aries masks that. It doesn't really mean that we'are not having souch issues as you had with pax-web. It's just handled by Aries, and even if Aries is very good, it sometimes just fails as every generic purpose tool. I don't push many contibutions to Karaf these days, however I heavily use it on daily basics, and I am hit by some problems (NullPointers in cm-blueprint internals, hangouts when using dev:watch, lack of initial update call when cm:managed-properties are used). Fact that we don't see threading issues with Aries doesn't really mean it doesn't have it. If you close eyes, world still exists. This is proven. :-)
Here, going into detail - Aries in our use case in 90% is limited to startup time. So if the service we would like to publish depens on two mandatory references we just should hold registration untill dependencies are satisfied. We know what dependencies are, proxy factory keeps eye on it so we'll catch moment when everything pops in. Just by counting open/close calls we will be able to call registration callback. We can at least try doing that. In theory, if we'll solve most complicated use case, we now have in Karaf, other things should raise smaller issues.
On configuration side - declarative services are all about services, so we'll need to register ManagedService instance anyway and handle updaes on our own.
Cheers,
Łukasz Dywicki
--
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
Wiadomość napisana przez Guillaume Nodet <gn...@apache.org> w dniu 7 gru 2013, o godz. 16:15:
> I don't count the number of weeks I've spent during the last months fixing
> pure OSGi code for concurrency and thread safety issues. And that includes
> Karaf, Pax-Web, Blueprint, Fabric and even SCR. Service trackers are nice
> tools, but not sufficient at all when it comes to handle multiple service
> dependencies along with configuration changes.
> Of course, registering commands is quite easy whatever method we use (pure
> OSGi, DS, blueprint or any other tool).
>
> Let's consider a simple use case: a bundle which expose an OSGi service
> which has 2 service dependencies and a configuration. Can you show me a
> pure OSGi code that does it in a safe way ?
>
> Guillaume
>
>
> 2013/12/7 Łukasz Dywicki <lu...@code-house.org>
>
>> All pax libraries we have deployed in Karaf are written without any piece
>> of injection frameworks. Starting from pax logging over pax web, to pax
>> wicket even (it supports blueprint namespaces but does not use it for
>> service tracking).
>>
>> On other hand, does registration of commands is so hard that could not be
>> done from Activator code? I don't think so. Most critical place which will
>> be affected is actually a tracker, which will need to be registered by us.
>> Indeed we'll get more code to maintain, but that's just matter of good
>> modularization to keep it clean. Honestly, most of complications we have is
>> hiden in service implementations. That's why I do consider dropping of
>> dependency injection framework. It is something which can be done, it's
>> just matter of balance between cons and pros.
>>
>> Best regards,
>> Łukasz Dywicki
>> --
>> luke@code-house.org
>> Twitter: ldywicki
>> Blog: http://dywicki.pl
>> Code-House - http://code-house.org
>>
>> Wiadomość napisana przez Christian Schneider <ch...@die-schneider.net> w
>> dniu 7 gru 2013, o godz. 13:14:
>>
>>> I went the pure OSGi way for CXF DOSGi. It works but is quite error
>> prone as you have to handle the dynamics of services and config yourself.
>> As DOSGi is a pretty small project I think it was worth the effort for
>> getting rid of DI dependencies.
>>>
>>> For karaf I would not like to have to do this for every service and
>> command bundle. DS might work quite well there.
>>> I have looked into the source from Ioannis. He uses SCR annotations for
>> the wiring and the felix scr plugin to generate the xml. So it looks like
>> not to much effort. The learning curve is of course there but I think with
>> some good example projects it should be relatively easy.
>>>
>>> I have not yet seen how the SCR annotations handle config injection. I
>> hope it works equally well.
>>>
>>> Christian
>>>
>>>
>>> Am 06.12.2013 23:05, schrieb Łukasz Dywicki:
>>>> 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
>>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>
>>
Re: A Blueprint Free Karaf
Posted by Guillaume Nodet <gn...@apache.org>.
I don't count the number of weeks I've spent during the last months fixing
pure OSGi code for concurrency and thread safety issues. And that includes
Karaf, Pax-Web, Blueprint, Fabric and even SCR. Service trackers are nice
tools, but not sufficient at all when it comes to handle multiple service
dependencies along with configuration changes.
Of course, registering commands is quite easy whatever method we use (pure
OSGi, DS, blueprint or any other tool).
Let's consider a simple use case: a bundle which expose an OSGi service
which has 2 service dependencies and a configuration. Can you show me a
pure OSGi code that does it in a safe way ?
Guillaume
2013/12/7 Łukasz Dywicki <lu...@code-house.org>
> All pax libraries we have deployed in Karaf are written without any piece
> of injection frameworks. Starting from pax logging over pax web, to pax
> wicket even (it supports blueprint namespaces but does not use it for
> service tracking).
>
> On other hand, does registration of commands is so hard that could not be
> done from Activator code? I don't think so. Most critical place which will
> be affected is actually a tracker, which will need to be registered by us.
> Indeed we'll get more code to maintain, but that's just matter of good
> modularization to keep it clean. Honestly, most of complications we have is
> hiden in service implementations. That's why I do consider dropping of
> dependency injection framework. It is something which can be done, it's
> just matter of balance between cons and pros.
>
> Best regards,
> Łukasz Dywicki
> --
> luke@code-house.org
> Twitter: ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
> Wiadomość napisana przez Christian Schneider <ch...@die-schneider.net> w
> dniu 7 gru 2013, o godz. 13:14:
>
> > I went the pure OSGi way for CXF DOSGi. It works but is quite error
> prone as you have to handle the dynamics of services and config yourself.
> As DOSGi is a pretty small project I think it was worth the effort for
> getting rid of DI dependencies.
> >
> > For karaf I would not like to have to do this for every service and
> command bundle. DS might work quite well there.
> > I have looked into the source from Ioannis. He uses SCR annotations for
> the wiring and the felix scr plugin to generate the xml. So it looks like
> not to much effort. The learning curve is of course there but I think with
> some good example projects it should be relatively easy.
> >
> > I have not yet seen how the SCR annotations handle config injection. I
> hope it works equally well.
> >
> > Christian
> >
> >
> > Am 06.12.2013 23:05, schrieb Łukasz Dywicki:
> >> 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
> >>
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > Talend Application Integration Division http://www.talend.com
> >
>
>
Re: A Blueprint Free Karaf
Posted by Łukasz Dywicki <lu...@code-house.org>.
All pax libraries we have deployed in Karaf are written without any piece of injection frameworks. Starting from pax logging over pax web, to pax wicket even (it supports blueprint namespaces but does not use it for service tracking).
On other hand, does registration of commands is so hard that could not be done from Activator code? I don't think so. Most critical place which will be affected is actually a tracker, which will need to be registered by us. Indeed we'll get more code to maintain, but that's just matter of good modularization to keep it clean. Honestly, most of complications we have is hiden in service implementations. That's why I do consider dropping of dependency injection framework. It is something which can be done, it's just matter of balance between cons and pros.
Best regards,
Łukasz Dywicki
--
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
Wiadomość napisana przez Christian Schneider <ch...@die-schneider.net> w dniu 7 gru 2013, o godz. 13:14:
> I went the pure OSGi way for CXF DOSGi. It works but is quite error prone as you have to handle the dynamics of services and config yourself. As DOSGi is a pretty small project I think it was worth the effort for getting rid of DI dependencies.
>
> For karaf I would not like to have to do this for every service and command bundle. DS might work quite well there.
> I have looked into the source from Ioannis. He uses SCR annotations for the wiring and the felix scr plugin to generate the xml. So it looks like not to much effort. The learning curve is of course there but I think with some good example projects it should be relatively easy.
>
> I have not yet seen how the SCR annotations handle config injection. I hope it works equally well.
>
> Christian
>
>
> Am 06.12.2013 23:05, schrieb Łukasz Dywicki:
>> 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
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: A Blueprint Free Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
I went the pure OSGi way for CXF DOSGi. It works but is quite error
prone as you have to handle the dynamics of services and config
yourself. As DOSGi is a pretty small project I think it was worth the
effort for getting rid of DI dependencies.
For karaf I would not like to have to do this for every service and
command bundle. DS might work quite well there.
I have looked into the source from Ioannis. He uses SCR annotations for
the wiring and the felix scr plugin to generate the xml. So it looks
like not to much effort. The learning curve is of course there but I
think with some good example projects it should be relatively easy.
I have not yet seen how the SCR annotations handle config injection. I
hope it works equally well.
Christian
Am 06.12.2013 23:05, schrieb Łukasz Dywicki:
> 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
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: A Blueprint Free Karaf
Posted by Łukasz Dywicki <lu...@code-house.org>.
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 <se...@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 <gn...@apache.org> wrote:
>
>> 2013/12/5 Daniel Kulp <dk...@apache.org>
>>
>>>
>>> On Dec 5, 2013, at 11:03 AM, Achim Nierbeck <bc...@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 <se...@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 <gn...@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. <ja...@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 <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é
>>>>>>>>>>>> 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/>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>
Re: A Blueprint Free Karaf
Posted by Johan Edstrom <se...@gmail.com>.
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 <gn...@apache.org> wrote:
> 2013/12/5 Daniel Kulp <dk...@apache.org>
>
>>
>> On Dec 5, 2013, at 11:03 AM, Achim Nierbeck <bc...@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 <se...@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 <gn...@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. <ja...@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 <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é
>>>>>>>>>>> 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/>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
Re: A Blueprint Free Karaf
Posted by Guillaume Nodet <gn...@apache.org>.
2013/12/5 Daniel Kulp <dk...@apache.org>
>
> On Dec 5, 2013, at 11:03 AM, Achim Nierbeck <bc...@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 <se...@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 <gn...@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. <ja...@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 <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é
> >>>>>>>>> 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/>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: A Blueprint Free Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
Removing blueprint from karaf is a change I would reserve for karaf 4.
In 3.x we could simply switch to DS but still provide blueprint by
default. We would also create a blueprint feature in 3.x and 2.x. CXF
could then start depending on the blueprint feature. The for karaf 4 we
would simply remove the blueprint bundles from the standard feature.
So we could manage to do the big internal changes very soon and still
stay compatible till the new major version.
Christian
Am 05.12.2013 17:40, schrieb Daniel Kulp:
> On Dec 5, 2013, at 11:03 AM, Achim Nierbeck <bc...@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.
>
> Dan
>
>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: A Blueprint Free Karaf
Posted by Guillaume Nodet <gn...@apache.org>.
2013/12/5 Łukasz Dywicki <lu...@code-house.org>
> <...> If we would step off blueprint then I do not consider DS or SCR as
> an alternative to blueprint since it's just another dependency and XML to
> maintain. <...>
>
Could you rephrase please, I'm not sure to understand your thoughts ?
>
> Cheers,
> Lukasz
>
> Wiadomość napisana przez Ioannis Canellos <io...@gmail.com> w dniu 5
> gru 2013, o godz. 18:13:
>
> >> 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.
> >
> > Regardless of the version that we introduce the change, the described
> > impact is unavoidable.
> > Since we do have 2 distributions (main & minimal) we could keep
> > blueprint by default in the main, add a blueprint feature in all new
> > releases (3.x and 2.x) and at some point in the future we can revisit
> > (when we have a decent range of karaf versions with the blueprint
> > feature in it).
> >
> > --
> > Ioannis Canellos
> >
> > Blog: http://iocanel.blogspot.com
> > Twitter: iocanel
>
>
Re: A Blueprint Free Karaf
Posted by Łukasz Dywicki <lu...@code-house.org>.
I am late for this discussion, however will try to put my fingers here. :)
I think that doing souch change in Karaf 3.1 will be good steep, since it's too late for closest release. If we would step off blueprint then I do not consider DS or SCR as an alternative to blueprint since it's just another dependency and XML to maintain. Some users were requesting support for gemini, since we will be blueprint free it will be easier to build support for that.
Cheers,
Lukasz
Wiadomość napisana przez Ioannis Canellos <io...@gmail.com> w dniu 5 gru 2013, o godz. 18:13:
>> 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.
>
> Regardless of the version that we introduce the change, the described
> impact is unavoidable.
> Since we do have 2 distributions (main & minimal) we could keep
> blueprint by default in the main, add a blueprint feature in all new
> releases (3.x and 2.x) and at some point in the future we can revisit
> (when we have a decent range of karaf versions with the blueprint
> feature in it).
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel
Re: A Blueprint Free Karaf
Posted by Ioannis Canellos <io...@gmail.com>.
> 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.
Regardless of the version that we introduce the change, the described
impact is unavoidable.
Since we do have 2 distributions (main & minimal) we could keep
blueprint by default in the main, add a blueprint feature in all new
releases (3.x and 2.x) and at some point in the future we can revisit
(when we have a decent range of karaf versions with the blueprint
feature in it).
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: A Blueprint Free Karaf
Posted by Daniel Kulp <dk...@apache.org>.
On Dec 5, 2013, at 11:03 AM, Achim Nierbeck <bc...@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.
Dan
>
> regards, Achim
>
>
> 2013/12/5 Johan Edstrom <se...@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 <gn...@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. <ja...@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 <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é
>>>>>>>>> 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/>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: A Blueprint Free Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <se...@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 <gn...@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. <ja...@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 <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é
> >>>>>>> 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/>
Re: A Blueprint Free Karaf
Posted by Johan Edstrom <se...@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 <gn...@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. <ja...@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 <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é
>>>>>>> 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
Re: A Blueprint Free Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <gn...@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. <ja...@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 <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é
>>>>>> 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
Re: A Blueprint Free Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <gn...@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. <ja...@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 <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é
>>>>> 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/>
Re: A Blueprint Free Karaf
Posted by 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 <gn...@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. <ja...@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 <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é
>>>> 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
Re: A Blueprint Free Karaf
Posted by Daniel Kulp <dk...@apache.org>.
On Dec 5, 2013, at 7:31 AM, Guillaume Nodet <gn...@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. <ja...@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 <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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: A Blueprint Free Karaf
Posted by Ioannis Canellos <io...@gmail.com>.
Regardless of the impact of this change, the apis provided by Karaf
are not affected. The only thing that is affected is the way that
services are wired together and of course the bundles that are started
up by default.
So I think that it could be delivered as a minor release of 3.x or
even 2.x (e.g. 2.4).
We don't want to stall 3.0.0 any longer. We also don't want to
maintain 3 different major branches. Since moving it to 3.1 totally
respects semantic versioning, I think that we could go with that.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: A Blueprint Free Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
I agree the change to DS can be done in a compatible way.
So from my point of view 3.x sounds good.
It will make backporting changes to earlier 3.0.x more difficult but if
the change is compatible enough we will only need to backport real
bugfixes so it should not be a big issue.
Christian
On 05.12.2013 13:31, Guillaume Nodet 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. <ja...@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 <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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: A Blueprint Free Karaf
Posted by "Jamie G." <ja...@gmail.com>.
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 <gn...@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. <ja...@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 <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é
> > > jbonofre@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
> >
>
Re: A Blueprint Free Karaf
Posted by Guillaume Nodet <gn...@apache.org>.
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. <ja...@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 <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é
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
Re: A Blueprint Free Karaf
Posted by "Jamie G." <ja...@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 <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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: A Blueprint Free Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: A Blueprint Free Karaf
Posted by Ioannis Canellos <io...@gmail.com>.
I would like to clarify, that DS is not an alternative DI framework.
It's more like a component framework that shines at managing the
lifecycle/dependencies of components than anything else.
Karaf itself hardly ever use traditional DI. So far it has been using
Blueprint in order to wire services together (in a DI like manner).
But do not get yourself confused, the fact that is handling services
in a DI-syle manner does not mean that Karaf is heavily relying on DI.
What I want to say, is that the whole idea of this poc, is to promote
a better way to handle services inside Karaf. It has nothing to do
with DI.
Re: A Blueprint Free Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
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
>>
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: A Blueprint Free Karaf
Posted by Guillaume Nodet <gn...@apache.org>.
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
>
>
Re: A Blueprint Free Karaf
Posted by 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.
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
Re: A Blueprint Free Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
OK,
i guess I missed it, cause I did look for the package commands, and those
are still blueprint,
but this is ok cause it's a POC (afaic)
still a support for commands with blueprint should be kept, though for a
"blueprint-less" Karaf we need the commands to work that way also :)
I really like that idea
regards, Achim
2013/12/5 Guillaume Nodet <gn...@apache.org>
> The migration seems to have been done already and I've just spotted that
> the support for blueprint commands seems still present, though in a
> different bundle.
>
>
> 2013/12/5 Achim Nierbeck <bc...@googlemail.com>
>
> > I think this is definitely something for a 4.x line, it's just to major
> > switch.
> > How will it fit in with all our commands, do we convert those too?
> > These are all bound to blueprint.
> >
> > regards, Achim
> >
> >
> > 2013/12/5 Andreas Pieber <an...@gmail.com>
> >
> > > Even for the a bit fuller one I think. Why should the karaf core need a
> > > dependency on blueprint?
> > >
> > > Kind regards, Andreas
> > >
> > > PS: for a real adaption to karaf I would rather consider this for the
> 3.x
> > > or 4.x line...
> > > On 5 Dec 2013 06:40, "Achim Nierbeck" <bc...@googlemail.com> wrote:
> > >
> > > > yeah, I already did grab myself a copy of it ;)
> > > >
> > > > for the minimal distribution this makes a lot of sense :)
> > > >
> > > > regards, Achim
> > > >
> > > >
> > > > 2013/12/5 Jean-Baptiste Onofré <jb...@nanthrax.net>
> > > >
> > > > > Hi Ioannis,
> > > > >
> > > > > it sounds interesting. I gonna take a look on that.
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > >
> > > > > On 12/04/2013 09:41 PM, 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)
> > > > >>
> > > > >>
> > > > > --
> > > > > 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/>
> > > >
> > >
> >
> >
> >
> > --
> >
> > 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/>
> >
>
--
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/>
Re: A Blueprint Free Karaf
Posted by Guillaume Nodet <gn...@apache.org>.
The migration seems to have been done already and I've just spotted that
the support for blueprint commands seems still present, though in a
different bundle.
2013/12/5 Achim Nierbeck <bc...@googlemail.com>
> I think this is definitely something for a 4.x line, it's just to major
> switch.
> How will it fit in with all our commands, do we convert those too?
> These are all bound to blueprint.
>
> regards, Achim
>
>
> 2013/12/5 Andreas Pieber <an...@gmail.com>
>
> > Even for the a bit fuller one I think. Why should the karaf core need a
> > dependency on blueprint?
> >
> > Kind regards, Andreas
> >
> > PS: for a real adaption to karaf I would rather consider this for the 3.x
> > or 4.x line...
> > On 5 Dec 2013 06:40, "Achim Nierbeck" <bc...@googlemail.com> wrote:
> >
> > > yeah, I already did grab myself a copy of it ;)
> > >
> > > for the minimal distribution this makes a lot of sense :)
> > >
> > > regards, Achim
> > >
> > >
> > > 2013/12/5 Jean-Baptiste Onofré <jb...@nanthrax.net>
> > >
> > > > Hi Ioannis,
> > > >
> > > > it sounds interesting. I gonna take a look on that.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > >
> > > > On 12/04/2013 09:41 PM, 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)
> > > >>
> > > >>
> > > > --
> > > > 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/>
> > >
> >
>
>
>
> --
>
> 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/>
>
Re: A Blueprint Free Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1 for 4.x line.
Regards
JB
On 12/05/2013 09:44 AM, Achim Nierbeck wrote:
> I think this is definitely something for a 4.x line, it's just to major
> switch.
> How will it fit in with all our commands, do we convert those too?
> These are all bound to blueprint.
>
> regards, Achim
>
>
> 2013/12/5 Andreas Pieber <an...@gmail.com>
>
>> Even for the a bit fuller one I think. Why should the karaf core need a
>> dependency on blueprint?
>>
>> Kind regards, Andreas
>>
>> PS: for a real adaption to karaf I would rather consider this for the 3.x
>> or 4.x line...
>> On 5 Dec 2013 06:40, "Achim Nierbeck" <bc...@googlemail.com> wrote:
>>
>>> yeah, I already did grab myself a copy of it ;)
>>>
>>> for the minimal distribution this makes a lot of sense :)
>>>
>>> regards, Achim
>>>
>>>
>>> 2013/12/5 Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>
>>>> Hi Ioannis,
>>>>
>>>> it sounds interesting. I gonna take a look on that.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 12/04/2013 09:41 PM, 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)
>>>>>
>>>>>
>>>> --
>>>> 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/>
>>>
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: A Blueprint Free Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
I think this is definitely something for a 4.x line, it's just to major
switch.
How will it fit in with all our commands, do we convert those too?
These are all bound to blueprint.
regards, Achim
2013/12/5 Andreas Pieber <an...@gmail.com>
> Even for the a bit fuller one I think. Why should the karaf core need a
> dependency on blueprint?
>
> Kind regards, Andreas
>
> PS: for a real adaption to karaf I would rather consider this for the 3.x
> or 4.x line...
> On 5 Dec 2013 06:40, "Achim Nierbeck" <bc...@googlemail.com> wrote:
>
> > yeah, I already did grab myself a copy of it ;)
> >
> > for the minimal distribution this makes a lot of sense :)
> >
> > regards, Achim
> >
> >
> > 2013/12/5 Jean-Baptiste Onofré <jb...@nanthrax.net>
> >
> > > Hi Ioannis,
> > >
> > > it sounds interesting. I gonna take a look on that.
> > >
> > > Regards
> > > JB
> > >
> > >
> > > On 12/04/2013 09:41 PM, 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)
> > >>
> > >>
> > > --
> > > 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/>
> >
>
--
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/>
Re: A Blueprint Free Karaf
Posted by Andreas Pieber <an...@gmail.com>.
Even for the a bit fuller one I think. Why should the karaf core need a
dependency on blueprint?
Kind regards, Andreas
PS: for a real adaption to karaf I would rather consider this for the 3.x
or 4.x line...
On 5 Dec 2013 06:40, "Achim Nierbeck" <bc...@googlemail.com> wrote:
> yeah, I already did grab myself a copy of it ;)
>
> for the minimal distribution this makes a lot of sense :)
>
> regards, Achim
>
>
> 2013/12/5 Jean-Baptiste Onofré <jb...@nanthrax.net>
>
> > Hi Ioannis,
> >
> > it sounds interesting. I gonna take a look on that.
> >
> > Regards
> > JB
> >
> >
> > On 12/04/2013 09:41 PM, 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)
> >>
> >>
> > --
> > 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/>
>
Re: A Blueprint Free Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
yeah, I already did grab myself a copy of it ;)
for the minimal distribution this makes a lot of sense :)
regards, Achim
2013/12/5 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Hi Ioannis,
>
> it sounds interesting. I gonna take a look on that.
>
> Regards
> JB
>
>
> On 12/04/2013 09:41 PM, 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)
>>
>>
> --
> 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/>
Re: A Blueprint Free Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Ioannis,
it sounds interesting. I gonna take a look on that.
Regards
JB
On 12/04/2013 09:41 PM, 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)
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: A Blueprint Free Karaf
Posted by Ehsan Zaery Moghaddam <za...@gmail.com>.
Hi all
Having a Blueprint free Karaf is a good idea, but it seems a big step in
developing Karaf. Thanks to JB, the Karaf 3.0 release has almost finished
and I think such a big change (till become stable enough) will cause an
unplanned delay in releasing this version. After Karaf 3.0, we will have
enough time to evaluate this new branch and polish it.
Regards
Ehsan
On Thu, Dec 5, 2013 at 1:14 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> Hi Guillaume,
>
> I would prefer to wait after the Karaf 3.0.0 release. We are really close
> to the release (just a couple of minor issues and the documentation update).
>
> Regards
> JB
>
>
> On 12/05/2013 10:40 AM, Guillaume Nodet wrote:
>
>> Though, I'm not sure it makes sense to do 2 major releases with a 3 months
>> interval. We'll have to maintain the branches.
>>
>> Before taking a decision, I think we should first find out if Ioannis (or
>> others) want to work on rebasing the work on trunk (in a branch obviously)
>> in the next days and see how stable it is. If it can be stabilized in
>> the
>> very short term, we could consider including it for 3.0, else delay it for
>> 4.0.
>> So I think we should delay the decision a bit ... and first make sure we
>> all agree on the principles first.
>>
>> 2013/12/5 Andreas Pieber <an...@gmail.com>
>>
>> I would also be for 4.0. IMHO we dont have to wait all that long for a a
>>> major as we do/did for 3.x
>>>
>>> Kind regards,
>>> Andreas
>>>
>>>
>>> On Thu, Dec 5, 2013 at 10:14 AM, Achim Nierbeck <bcanhome@googlemail.com
>>>
>>>> wrote:
>>>>
>>>
>>> Guillaume,
>>>>
>>>> that's why I would go for 4.0 :)
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>> 2013/12/5 Guillaume Nodet <gn...@apache.org>
>>>>
>>>> Forking a git repo is really the easiest way to experiment imho. If
>>>>> there's a consensus, we can port all the changes to the karaf repo and
>>>>> maintain it in Karaf, else it will certainly be dropped.
>>>>>
>>>>> +1 too on both ideas (trim down minimal and switch to scr)
>>>>>
>>>>> The question I wonder about is which version to put that in. I don't
>>>>> really see that as a minor change, so I'm tempted to push that into
>>>>>
>>>> 3.0,
>>>
>>>> but if we do, it will delay it even more.
>>>>>
>>>>>
>>>>>
>>>>> 2013/12/5 Andreas Pieber <an...@gmail.com>
>>>>>
>>>>> I'm with David on this one. I would even have no problems if the
>>>>>>
>>>>> minimal
>>>>
>>>>> distribution would really look like your fork. The only problem is
>>>>>>
>>>>> that
>>>
>>>> forking isn't just the best way to maintain a project :-)
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 4, 2013 at 10:00 PM, David Jencks <
>>>>>>
>>>>> david_jencks@yahoo.com
>>>
>>>> wrote:
>>>>>>>
>>>>>>
>>>>>> Great idea! I think that scr/ds is better suited to framework
>>>>>>>
>>>>>> service
>>>>
>>>>> wiring than blueprint.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea <hz...@gmail.com>
>>>>>>>
>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>> Sounds very interesting. Less is more. I absolutely need to try
>>>>>>>>
>>>>>>> this
>>>>
>>>>> :).
>>>>>>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Hadrian
>>>>>>>>
>>>>>>>> On 12/04/2013 03:41 PM, 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)
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> 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/>
>>>>
>>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: A Blueprint Free Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Guillaume,
I would prefer to wait after the Karaf 3.0.0 release. We are really
close to the release (just a couple of minor issues and the
documentation update).
Regards
JB
On 12/05/2013 10:40 AM, Guillaume Nodet wrote:
> Though, I'm not sure it makes sense to do 2 major releases with a 3 months
> interval. We'll have to maintain the branches.
>
> Before taking a decision, I think we should first find out if Ioannis (or
> others) want to work on rebasing the work on trunk (in a branch obviously)
> in the next days and see how stable it is. If it can be stabilized in the
> very short term, we could consider including it for 3.0, else delay it for
> 4.0.
> So I think we should delay the decision a bit ... and first make sure we
> all agree on the principles first.
>
> 2013/12/5 Andreas Pieber <an...@gmail.com>
>
>> I would also be for 4.0. IMHO we dont have to wait all that long for a a
>> major as we do/did for 3.x
>>
>> Kind regards,
>> Andreas
>>
>>
>> On Thu, Dec 5, 2013 at 10:14 AM, Achim Nierbeck <bcanhome@googlemail.com
>>> wrote:
>>
>>> Guillaume,
>>>
>>> that's why I would go for 4.0 :)
>>>
>>> regards, Achim
>>>
>>>
>>> 2013/12/5 Guillaume Nodet <gn...@apache.org>
>>>
>>>> Forking a git repo is really the easiest way to experiment imho. If
>>>> there's a consensus, we can port all the changes to the karaf repo and
>>>> maintain it in Karaf, else it will certainly be dropped.
>>>>
>>>> +1 too on both ideas (trim down minimal and switch to scr)
>>>>
>>>> The question I wonder about is which version to put that in. I don't
>>>> really see that as a minor change, so I'm tempted to push that into
>> 3.0,
>>>> but if we do, it will delay it even more.
>>>>
>>>>
>>>>
>>>> 2013/12/5 Andreas Pieber <an...@gmail.com>
>>>>
>>>>> I'm with David on this one. I would even have no problems if the
>>> minimal
>>>>> distribution would really look like your fork. The only problem is
>> that
>>>>> forking isn't just the best way to maintain a project :-)
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>>
>>>>> On Wed, Dec 4, 2013 at 10:00 PM, David Jencks <
>> david_jencks@yahoo.com
>>>>>> wrote:
>>>>>
>>>>>> Great idea! I think that scr/ds is better suited to framework
>>> service
>>>>>> wiring than blueprint.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea <hz...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> Sounds very interesting. Less is more. I absolutely need to try
>>> this
>>>>> :).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Hadrian
>>>>>>>
>>>>>>> On 12/04/2013 03:41 PM, 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)
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> 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/>
>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: A Blueprint Free Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
Ioannis, grmpf I guess your're right got the wrong branch .... should stop
working late at night. :)
I'm gonna do a better research on the karaf-light branch ;)
thanks for the pointer.
2013/12/5 Ioannis Canellos <io...@gmail.com>
> @Achim: package commands do use SCR (are you looking at the
> karat-light branch?).
> @Andreas: The github fork serves just experimentation purposes. This
> idea could be hardly presented as a patch or a pull request (so it
> needed its own branch).
> @Guillaume: I wouldn't want this idea to be yet an other reason to
> stall 3.0. If the features justify it a quick new major release sounds
> ok to me. Of course rebasing to the current trunk (3.0) is something
> that needs to happen anyway. So the real question is "can that rebase
> happen before we release 3.0?". If so, everything is ok. If not, then
> I guess we will have to bear the burden of maintaining 2.3, 3.x & 4.x
> for a while. If 3.0 is something that is going to happen next week or
> the week after I could do some late nights to rebase to 3.0 (helping
> hands are more than welcome).
>
> wdyt?
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel
>
--
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/>
Re: A Blueprint Free Karaf
Posted by Ioannis Canellos <io...@gmail.com>.
@Achim: package commands do use SCR (are you looking at the
karat-light branch?).
@Andreas: The github fork serves just experimentation purposes. This
idea could be hardly presented as a patch or a pull request (so it
needed its own branch).
@Guillaume: I wouldn't want this idea to be yet an other reason to
stall 3.0. If the features justify it a quick new major release sounds
ok to me. Of course rebasing to the current trunk (3.0) is something
that needs to happen anyway. So the real question is "can that rebase
happen before we release 3.0?". If so, everything is ok. If not, then
I guess we will have to bear the burden of maintaining 2.3, 3.x & 4.x
for a while. If 3.0 is something that is going to happen next week or
the week after I could do some late nights to rebase to 3.0 (helping
hands are more than welcome).
wdyt?
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: A Blueprint Free Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
Even though I really appreciate this proof of concept on minimizing the
Karaf footprint.
I'm also a bit sad that as far as I can tell right now JB seems to be a
lonely wolf on finishing up Karaf 3.0.
I would really had hoped for some more community power on our upcoming
release 3.0.
I know all of us are kind of bound to different projects/jobs still we
really could need some more momentum on this
especially since we're so close on releasing 3.0,
and I know Jamie is really desperate in opening that bottle for it ;)
At this point I would rather see a 3.1 or 4.0 containing this then 3.0
regards, Achim
2013/12/5 Guillaume Nodet <gn...@apache.org>
> Though, I'm not sure it makes sense to do 2 major releases with a 3 months
> interval. We'll have to maintain the branches.
>
> Before taking a decision, I think we should first find out if Ioannis (or
> others) want to work on rebasing the work on trunk (in a branch obviously)
> in the next days and see how stable it is. If it can be stabilized in the
> very short term, we could consider including it for 3.0, else delay it for
> 4.0.
> So I think we should delay the decision a bit ... and first make sure we
> all agree on the principles first.
>
> 2013/12/5 Andreas Pieber <an...@gmail.com>
>
> > I would also be for 4.0. IMHO we dont have to wait all that long for a a
> > major as we do/did for 3.x
> >
> > Kind regards,
> > Andreas
> >
> >
> > On Thu, Dec 5, 2013 at 10:14 AM, Achim Nierbeck <bcanhome@googlemail.com
> > >wrote:
> >
> > > Guillaume,
> > >
> > > that's why I would go for 4.0 :)
> > >
> > > regards, Achim
> > >
> > >
> > > 2013/12/5 Guillaume Nodet <gn...@apache.org>
> > >
> > > > Forking a git repo is really the easiest way to experiment imho. If
> > > > there's a consensus, we can port all the changes to the karaf repo
> and
> > > > maintain it in Karaf, else it will certainly be dropped.
> > > >
> > > > +1 too on both ideas (trim down minimal and switch to scr)
> > > >
> > > > The question I wonder about is which version to put that in. I don't
> > > > really see that as a minor change, so I'm tempted to push that into
> > 3.0,
> > > > but if we do, it will delay it even more.
> > > >
> > > >
> > > >
> > > > 2013/12/5 Andreas Pieber <an...@gmail.com>
> > > >
> > > > > I'm with David on this one. I would even have no problems if the
> > > minimal
> > > > > distribution would really look like your fork. The only problem is
> > that
> > > > > forking isn't just the best way to maintain a project :-)
> > > > >
> > > > > Kind regards,
> > > > > Andreas
> > > > >
> > > > >
> > > > > On Wed, Dec 4, 2013 at 10:00 PM, David Jencks <
> > david_jencks@yahoo.com
> > > > > >wrote:
> > > > >
> > > > > > Great idea! I think that scr/ds is better suited to framework
> > > service
> > > > > > wiring than blueprint.
> > > > > >
> > > > > > thanks
> > > > > > david jencks
> > > > > >
> > > > > > On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea <hzbarcea@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > Sounds very interesting. Less is more. I absolutely need to try
> > > this
> > > > > :).
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Hadrian
> > > > > > >
> > > > > > > On 12/04/2013 03:41 PM, 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)
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > 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/>
> > >
> >
>
--
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/>
Re: A Blueprint Free Karaf
Posted by Guillaume Nodet <gn...@apache.org>.
Though, I'm not sure it makes sense to do 2 major releases with a 3 months
interval. We'll have to maintain the branches.
Before taking a decision, I think we should first find out if Ioannis (or
others) want to work on rebasing the work on trunk (in a branch obviously)
in the next days and see how stable it is. If it can be stabilized in the
very short term, we could consider including it for 3.0, else delay it for
4.0.
So I think we should delay the decision a bit ... and first make sure we
all agree on the principles first.
2013/12/5 Andreas Pieber <an...@gmail.com>
> I would also be for 4.0. IMHO we dont have to wait all that long for a a
> major as we do/did for 3.x
>
> Kind regards,
> Andreas
>
>
> On Thu, Dec 5, 2013 at 10:14 AM, Achim Nierbeck <bcanhome@googlemail.com
> >wrote:
>
> > Guillaume,
> >
> > that's why I would go for 4.0 :)
> >
> > regards, Achim
> >
> >
> > 2013/12/5 Guillaume Nodet <gn...@apache.org>
> >
> > > Forking a git repo is really the easiest way to experiment imho. If
> > > there's a consensus, we can port all the changes to the karaf repo and
> > > maintain it in Karaf, else it will certainly be dropped.
> > >
> > > +1 too on both ideas (trim down minimal and switch to scr)
> > >
> > > The question I wonder about is which version to put that in. I don't
> > > really see that as a minor change, so I'm tempted to push that into
> 3.0,
> > > but if we do, it will delay it even more.
> > >
> > >
> > >
> > > 2013/12/5 Andreas Pieber <an...@gmail.com>
> > >
> > > > I'm with David on this one. I would even have no problems if the
> > minimal
> > > > distribution would really look like your fork. The only problem is
> that
> > > > forking isn't just the best way to maintain a project :-)
> > > >
> > > > Kind regards,
> > > > Andreas
> > > >
> > > >
> > > > On Wed, Dec 4, 2013 at 10:00 PM, David Jencks <
> david_jencks@yahoo.com
> > > > >wrote:
> > > >
> > > > > Great idea! I think that scr/ds is better suited to framework
> > service
> > > > > wiring than blueprint.
> > > > >
> > > > > thanks
> > > > > david jencks
> > > > >
> > > > > On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea <hz...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Sounds very interesting. Less is more. I absolutely need to try
> > this
> > > > :).
> > > > > >
> > > > > > Thanks,
> > > > > > Hadrian
> > > > > >
> > > > > > On 12/04/2013 03:41 PM, 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)
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > 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/>
> >
>
Re: A Blueprint Free Karaf
Posted by Andreas Pieber <an...@gmail.com>.
I would also be for 4.0. IMHO we dont have to wait all that long for a a
major as we do/did for 3.x
Kind regards,
Andreas
On Thu, Dec 5, 2013 at 10:14 AM, Achim Nierbeck <bc...@googlemail.com>wrote:
> Guillaume,
>
> that's why I would go for 4.0 :)
>
> regards, Achim
>
>
> 2013/12/5 Guillaume Nodet <gn...@apache.org>
>
> > Forking a git repo is really the easiest way to experiment imho. If
> > there's a consensus, we can port all the changes to the karaf repo and
> > maintain it in Karaf, else it will certainly be dropped.
> >
> > +1 too on both ideas (trim down minimal and switch to scr)
> >
> > The question I wonder about is which version to put that in. I don't
> > really see that as a minor change, so I'm tempted to push that into 3.0,
> > but if we do, it will delay it even more.
> >
> >
> >
> > 2013/12/5 Andreas Pieber <an...@gmail.com>
> >
> > > I'm with David on this one. I would even have no problems if the
> minimal
> > > distribution would really look like your fork. The only problem is that
> > > forking isn't just the best way to maintain a project :-)
> > >
> > > Kind regards,
> > > Andreas
> > >
> > >
> > > On Wed, Dec 4, 2013 at 10:00 PM, David Jencks <david_jencks@yahoo.com
> > > >wrote:
> > >
> > > > Great idea! I think that scr/ds is better suited to framework
> service
> > > > wiring than blueprint.
> > > >
> > > > thanks
> > > > david jencks
> > > >
> > > > On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea <hz...@gmail.com>
> > wrote:
> > > >
> > > > > Sounds very interesting. Less is more. I absolutely need to try
> this
> > > :).
> > > > >
> > > > > Thanks,
> > > > > Hadrian
> > > > >
> > > > > On 12/04/2013 03:41 PM, 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)
> > > > >>
> > > >
> > > >
> > >
> >
>
>
>
> --
>
> 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/>
>
Re: A Blueprint Free Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
Guillaume,
that's why I would go for 4.0 :)
regards, Achim
2013/12/5 Guillaume Nodet <gn...@apache.org>
> Forking a git repo is really the easiest way to experiment imho. If
> there's a consensus, we can port all the changes to the karaf repo and
> maintain it in Karaf, else it will certainly be dropped.
>
> +1 too on both ideas (trim down minimal and switch to scr)
>
> The question I wonder about is which version to put that in. I don't
> really see that as a minor change, so I'm tempted to push that into 3.0,
> but if we do, it will delay it even more.
>
>
>
> 2013/12/5 Andreas Pieber <an...@gmail.com>
>
> > I'm with David on this one. I would even have no problems if the minimal
> > distribution would really look like your fork. The only problem is that
> > forking isn't just the best way to maintain a project :-)
> >
> > Kind regards,
> > Andreas
> >
> >
> > On Wed, Dec 4, 2013 at 10:00 PM, David Jencks <david_jencks@yahoo.com
> > >wrote:
> >
> > > Great idea! I think that scr/ds is better suited to framework service
> > > wiring than blueprint.
> > >
> > > thanks
> > > david jencks
> > >
> > > On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea <hz...@gmail.com>
> wrote:
> > >
> > > > Sounds very interesting. Less is more. I absolutely need to try this
> > :).
> > > >
> > > > Thanks,
> > > > Hadrian
> > > >
> > > > On 12/04/2013 03:41 PM, 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)
> > > >>
> > >
> > >
> >
>
--
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/>
Re: A Blueprint Free Karaf
Posted by Guillaume Nodet <gn...@apache.org>.
Forking a git repo is really the easiest way to experiment imho. If
there's a consensus, we can port all the changes to the karaf repo and
maintain it in Karaf, else it will certainly be dropped.
+1 too on both ideas (trim down minimal and switch to scr)
The question I wonder about is which version to put that in. I don't
really see that as a minor change, so I'm tempted to push that into 3.0,
but if we do, it will delay it even more.
2013/12/5 Andreas Pieber <an...@gmail.com>
> I'm with David on this one. I would even have no problems if the minimal
> distribution would really look like your fork. The only problem is that
> forking isn't just the best way to maintain a project :-)
>
> Kind regards,
> Andreas
>
>
> On Wed, Dec 4, 2013 at 10:00 PM, David Jencks <david_jencks@yahoo.com
> >wrote:
>
> > Great idea! I think that scr/ds is better suited to framework service
> > wiring than blueprint.
> >
> > thanks
> > david jencks
> >
> > On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> >
> > > Sounds very interesting. Less is more. I absolutely need to try this
> :).
> > >
> > > Thanks,
> > > Hadrian
> > >
> > > On 12/04/2013 03:41 PM, 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)
> > >>
> >
> >
>
Re: A Blueprint Free Karaf
Posted by Andreas Pieber <an...@gmail.com>.
I'm with David on this one. I would even have no problems if the minimal
distribution would really look like your fork. The only problem is that
forking isn't just the best way to maintain a project :-)
Kind regards,
Andreas
On Wed, Dec 4, 2013 at 10:00 PM, David Jencks <da...@yahoo.com>wrote:
> Great idea! I think that scr/ds is better suited to framework service
> wiring than blueprint.
>
> thanks
> david jencks
>
> On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>
> > Sounds very interesting. Less is more. I absolutely need to try this :).
> >
> > Thanks,
> > Hadrian
> >
> > On 12/04/2013 03:41 PM, 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)
> >>
>
>
Re: A Blueprint Free Karaf
Posted by David Jencks <da...@yahoo.com>.
Great idea! I think that scr/ds is better suited to framework service wiring than blueprint.
thanks
david jencks
On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Sounds very interesting. Less is more. I absolutely need to try this :).
>
> Thanks,
> Hadrian
>
> On 12/04/2013 03:41 PM, 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)
>>
Re: A Blueprint Free Karaf
Posted by "Jamie G." <ja...@gmail.com>.
Interesting project, taking a look see :)
--Jamie
On Wed, Dec 4, 2013 at 5:18 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Sounds very interesting. Less is more. I absolutely need to try this :).
>
> Thanks,
> Hadrian
>
>
> On 12/04/2013 03:41 PM, 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)
>>
>>
Re: A Blueprint Free Karaf
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Sounds very interesting. Less is more. I absolutely need to try this :).
Thanks,
Hadrian
On 12/04/2013 03:41 PM, 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)
>