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. <jamie.goody...@gmail.com>
Just wanted to contribute my 2 cents -- I'd look at a SCR Karaf for 4.0 -
removing Blueprint dependencies from the core is too major a change to try
to introduce it to 2.3.x or 3.0 at this stage.
--Jamie
On Thu, Dec 5, 2013 at 8:10 AM, Jean-Baptiste Onofré <j...@nanthrax.net
wrote:
I think we have to distinguish different things:
- the learn curve and usage "outside" of Karaf for developers. CDI is
like
EJB, and other framework.
- the usage of CDI "inside" an OSGi application or Karaf itself (or for
"native" OSGi applications).
The fact that Karaf now supports CDI (via pax-cdi) is as good as
supporting OpenEJB (in KarafEE), or Spring (in Karaf "natively").
I would not use OpenEJB in Karaf "itself", nor Spring, nor CDI.
If a developer wants to create a "generic" application (that can work in
both OSGi or non-OSGi containers), CDI is good.
If a developer want to create a native OSGi application, I would use
natively OSGi "specific" framework (like blueprint).
My 0.02€
Regards
JB
On 12/05/2013 12:06 PM, Christian Schneider wrote:
Probably you are right.
The reason why I came up with CDI is that it has the potential to be the
core of user applications.
It is fully featured regarding web and persistence if you include other
JavaEE stuff and also defines a standardized extension mechanism.
CDI is also well known to JavaEE developers. So my point is/was that CDI
may be the only thing a developer needs to learn regarding dependency
injection.
On the other hand a programmer of user applications running on karaf is
quite decoupled from the karaf services and commands.
So it is probably not necessary that he uses and understands the karaf
internals. So from this perspective minimum footprint counts more than
having only one framework. So from this point of view DS really is
better than CDI.
Another argument supporting this is that while I see most potential in
CDI to take over dependency injection in user space it is far from the
only solution. So there will always be people who use something else. As
karaf needs to support a wide range of frameworks this also speaks for
minimum footprint for karaf's internals.
Christian
On 05.12.2013 11:49, Guillaume Nodet wrote:
2013/12/5 Christian Schneider <ch...@die-schneider.net>
Good idea to look into alternatives to blueprint.
The big advantage I see for DS is that it is very light weight. I am
not
so sure about its long term future though.
I personally think the future of OSGi dependency injection is CDI like
pax-cdi + weld or openwebbeans.
Of course this is not really near term and far from being a sure bet.
Still I think if we switch the DI framework we should
also at least experiment with CDI. I am currently working on a karaf
tutorial for CDI. The service injections already work very well.
I am now looking into jpa support.
I disagree. CDI will have the same problems as blueprint, it's an
application level injection framework, not focused *primarily* on OSGi.
The lifecycle of CDI beans has to be static, so you have to use
proxies.
Blueprint has the exact same problem where the beans lifecycle is
bound to
the lifecycle of the container. On the opposite, DS has a better
lifecycle mechanism for beans which can naturally handle the OSGi
dynamism.
And CDI would be even more heavyweight than blueprint, so I'd rather
stick
with blueprint than switching to CDI, even if it were ready.
The real benefit of DS is that it has been designed to handle the OSGi
dynamism, so it does less, but it does it better.
In any case I think switching the DI framework should be considered
for
karaf 4. So in this case we have a bit of time to experiment.
Christian
On 04.12.2013 21:41, Ioannis Canellos wrote:
For anyone curious on how Karaf without Blueprint would look like,
here is a karaf branch that is free of blueprint:
https://github.com/iocanel/karaf/tree/karaf-light (it's a fork of
the
karat-2.3.x branch).
It is actually a refactored karaf 2.3.x that removes blueprint from
all modules (yet still provides blueprint as feaures). Karaf specific
blueprint namespace handlers have moved to optional bundles so that
they can still be used if needed.
Blueprint has been replaced with Felix SCR (including the shell
commands). Moreover, misc refactorings on features and startup
bundles
have been performed in order to reduce the size and the amount of
bundles in the minimal distro.
The result is a minimal distribution that starts 12 bundles [1] (out
of 37 which were part of karaf 2.3.3 minimal distro). 10 of those
bundle were blueprint bundles and the rest are extra noise.
My motivation behind this refactoring was:
i) I like declarative services more than blueprint.
ii) I've been working on projects that are packaged inside the karaf
minimal distro which would benefit from a smaller size (e.g.
jclouds-cli).
iii) I wanted to make a karaf distro as flexible as possible.
Please note that my main focus was the minimal distribution and also
this is not 100% polished.
Enjoy!
[1]: The bundle list of the minimal distro:
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (4.0.3)
[ 1] [Active ] [ 5] OPS4J Pax Url - mvn: (1.3.6)
[ 2] [Active ] [ 5] OPS4J Pax Url - wrap: (1.3.6)
[ 3] [Active ] [ 8] OPS4J Pax Logging - API (1.7.1)
[ 4] [Active ] [ 8] OPS4J Pax Logging - Service (1.7.1)
[ 5] [Active ] [ 10] Apache Felix Configuration Admin Service
(1.6.0)
[ 6] [Active ] [ 11] Apache Felix File Install (3.2.6)
[ 7] [Active ] [ 13] Apache Felix Declarative Services
(1.6.2)
[ 8] [Active ] [ 25] Apache Karaf :: Shell :: Console
(2.3.4.SNAPSHOT)
[ 9] [Active ] [ 30] Apache Karaf :: Features :: Core
(2.3.4.SNAPSHOT)
[ 10] [Active ] [ 30] Apache Karaf :: Features :: Command
(2.3.4.SNAPSHOT)
[ 11] [Active ] [ 30] Apache Karaf :: Shell :: Log Commands
(2.3.4.SNAPSHOT)
[ 12] [Active ] [ 30] Apache Karaf :: Shell :: OSGi Commands
(2.3.4.SNAPSHOT)
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
