Re: A Blueprint Free Karaf

[Guillaume Nodet]

2013/12/5 Daniel Kulp 

>
> On Dec 5, 2013, at 11:03 AM, Achim Nierbeck 
> 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 
> >
> >> 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é 
> 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é 
> 
> > 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 
> >> 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)
> 

Re: A Blueprint Free Karaf

[Hadrian Zbarcea]

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

[Guillaume Nodet]

2013/12/5 Łukasz Dywicki 

> <...>  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  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

[Łukasz Dywicki]

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  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: itests (trunk) on Mac osx (now with Java 7)

[Jean-Baptiste Onofré]

OK, it was the same problem as before: in the pax-http feature, 
replacing xbean-finder by xbean-finder-shaded works.


Let me check with Achim.

Regards
JB

On 12/05/2013 06:42 PM, Jean-Baptiste Onofré wrote:

We have the following issue in the itests:

Tests in error:

checkInteractionOfHttpAndAriesAnnotationFeature(org.apache.karaf.itests.features.StandardFeaturesTest):
Unresolved constraint in bundle org.apache.xbean.finder [190]: Unable to
resolve 190.0: missing requirement [190.0] osgi.wiring.package;
(&(osgi.wiring.package=org.objectweb.asm.signature)(version>=4.1.0))

installHttpWhiteboardFeature(org.apache.karaf.itests.features.StandardFeaturesTest):
Unresolved constraint in bundle org.apache.xbean.finder [217]: Unable to
resolve 217.0: missing requirement [217.0] osgi.wiring.package;
(&(osgi.wiring.package=org.objectweb.asm.signature)(version>=4.1.0))

installWebConsoleFeature(org.apache.karaf.itests.features.StandardFeaturesTest):
Unresolved constraint in bundle org.apache.xbean.finder [237]: Unable to
resolve 237.0: missing requirement [237.0] osgi.wiring.package;
(&(osgi.wiring.package=org.objectweb.asm.signature)(version>=4.1.0))


The issue comes from the Pax Web 3.0.4 update and a change in the Pax
Web feature (whereas I fixed that, I gonna check with Achim why he
changed the feature descriptor).

I'm fixing that and I will discuss with Achim.

Regards
JB

On 12/05/2013 05:07 PM, Jean-Baptiste Onofré wrote:

It worked in the beginning of this week. So I'm looking for the commit
that introduced this failure.

More over, I have a different itest failure on my machine.

Regards
JB

On 12/05/2013 05:04 PM, Andreas Pieber wrote:

Seams to be probem in RMI remoting. In [1] you find the exception. In
[2]
you see a bug which might be connected to it. I only did a VERY short
googling. But this seams to be kind of the problem.

Kind regards,
Andreas

[1]
http://svn.apache.org/repos/asf/karaf/tags/karaf-2.3.0/tooling/exam/container/src/main/java/org/apache/karaf/tooling/exam/container/internal/RMIRegistry.java



[2] http://bugs.sun.com/view_bug.do?bug_id=7166687


On Thu, Dec 5, 2013 at 4:58 PM, David Bosschaert

wrote:



Hi all,

I have updated to Java 7 on my Mac and am getting the errors below
with the itests [1]. They work fine for me on Linux. Also note that
all the other maven modules in karaf trunk test/pass fine for me.
Anyone an idea? I'm using the following Java:
   $ java -version
   java version "1.7.0_45"
   Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
   Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Thanks,

David

[1] All the itests fail as follows:
java.util.ServiceConfigurationError:
org.ops4j.pax.exam.TestContainerFactory: Provider
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory
could not be instantiated: java.lang.IllegalStateException: Cannot
select localhost. That usually not a good sign for networking..
at java.util.ServiceLoader.fail(ServiceLoader.java:224)
at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at
org.ops4j.pax.exam.spi.PaxExamRuntime.sanityCheck(PaxExamRuntime.java:172)


at
org.ops4j.pax.exam.spi.PaxExamRuntime.getTestContainerFactory(PaxExamRuntime.java:69)


at
org.ops4j.pax.exam.spi.reactors.ReactorManager.createsTestContainerFactory(ReactorManager.java:335)


at
org.ops4j.pax.exam.spi.reactors.ReactorManager.createReactor(ReactorManager.java:308)


at
org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)


at
org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:80)


at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)


at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)


at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)


at
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)


at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)


at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)


at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)


at
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)

at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)


at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)


at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)


at sun

Re: itests (trunk) on Mac osx (now with Java 7)

[Jean-Baptiste Onofré]

We have the following issue in the itests:

Tests in error:

checkInteractionOfHttpAndAriesAnnotationFeature(org.apache.karaf.itests.features.StandardFeaturesTest): 
Unresolved constraint in bundle org.apache.xbean.finder [190]: Unable to 
resolve 190.0: missing requirement [190.0] osgi.wiring.package; 
(&(osgi.wiring.package=org.objectweb.asm.signature)(version>=4.1.0))


installHttpWhiteboardFeature(org.apache.karaf.itests.features.StandardFeaturesTest): 
Unresolved constraint in bundle org.apache.xbean.finder [217]: Unable to 
resolve 217.0: missing requirement [217.0] osgi.wiring.package; 
(&(osgi.wiring.package=org.objectweb.asm.signature)(version>=4.1.0))


installWebConsoleFeature(org.apache.karaf.itests.features.StandardFeaturesTest): 
Unresolved constraint in bundle org.apache.xbean.finder [237]: Unable to 
resolve 237.0: missing requirement [237.0] osgi.wiring.package; 
(&(osgi.wiring.package=org.objectweb.asm.signature)(version>=4.1.0))



The issue comes from the Pax Web 3.0.4 update and a change in the Pax 
Web feature (whereas I fixed that, I gonna check with Achim why he 
changed the feature descriptor).


I'm fixing that and I will discuss with Achim.

Regards
JB

On 12/05/2013 05:07 PM, Jean-Baptiste Onofré wrote:

It worked in the beginning of this week. So I'm looking for the commit
that introduced this failure.

More over, I have a different itest failure on my machine.

Regards
JB

On 12/05/2013 05:04 PM, Andreas Pieber wrote:

Seams to be probem in RMI remoting. In [1] you find the exception. In [2]
you see a bug which might be connected to it. I only did a VERY short
googling. But this seams to be kind of the problem.

Kind regards,
Andreas

[1]
http://svn.apache.org/repos/asf/karaf/tags/karaf-2.3.0/tooling/exam/container/src/main/java/org/apache/karaf/tooling/exam/container/internal/RMIRegistry.java


[2] http://bugs.sun.com/view_bug.do?bug_id=7166687


On Thu, Dec 5, 2013 at 4:58 PM, David Bosschaert

wrote:



Hi all,

I have updated to Java 7 on my Mac and am getting the errors below
with the itests [1]. They work fine for me on Linux. Also note that
all the other maven modules in karaf trunk test/pass fine for me.
Anyone an idea? I'm using the following Java:
   $ java -version
   java version "1.7.0_45"
   Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
   Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Thanks,

David

[1] All the itests fail as follows:
java.util.ServiceConfigurationError:
org.ops4j.pax.exam.TestContainerFactory: Provider
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory
could not be instantiated: java.lang.IllegalStateException: Cannot
select localhost. That usually not a good sign for networking..
at java.util.ServiceLoader.fail(ServiceLoader.java:224)
at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at
org.ops4j.pax.exam.spi.PaxExamRuntime.sanityCheck(PaxExamRuntime.java:172)

at
org.ops4j.pax.exam.spi.PaxExamRuntime.getTestContainerFactory(PaxExamRuntime.java:69)

at
org.ops4j.pax.exam.spi.reactors.ReactorManager.createsTestContainerFactory(ReactorManager.java:335)

at
org.ops4j.pax.exam.spi.reactors.ReactorManager.createReactor(ReactorManager.java:308)

at
org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)

at
org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:80)

at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)

at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)

at
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)

at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)

at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)

at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)

at
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)

at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)

at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso

Re: A Blueprint Free Karaf

[Ioannis Canellos]

> 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

[Christian Schneider]

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  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

[Johan Edstrom]

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  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

[Daniel Kulp]

On Dec 5, 2013, at 11:03 AM, Achim Nierbeck  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 
> 
>> 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é  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é 
 
> 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 
>> 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. 
>>> 
>>> 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
>

Re: A Blueprint Free Karaf

[Ioannis Canellos]

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: itests (trunk) on Mac osx (now with Java 7)

[Jean-Baptiste Onofré]

It worked in the beginning of this week. So I'm looking for the commit 
that introduced this failure.


More over, I have a different itest failure on my machine.

Regards
JB

On 12/05/2013 05:04 PM, Andreas Pieber wrote:

Seams to be probem in RMI remoting. In [1] you find the exception. In [2]
you see a bug which might be connected to it. I only did a VERY short
googling. But this seams to be kind of the problem.

Kind regards,
Andreas

[1]
http://svn.apache.org/repos/asf/karaf/tags/karaf-2.3.0/tooling/exam/container/src/main/java/org/apache/karaf/tooling/exam/container/internal/RMIRegistry.java

[2] http://bugs.sun.com/view_bug.do?bug_id=7166687


On Thu, Dec 5, 2013 at 4:58 PM, David Bosschaert 
wrote:



Hi all,

I have updated to Java 7 on my Mac and am getting the errors below
with the itests [1]. They work fine for me on Linux. Also note that
all the other maven modules in karaf trunk test/pass fine for me.
Anyone an idea? I'm using the following Java:
   $ java -version
   java version "1.7.0_45"
   Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
   Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Thanks,

David

[1] All the itests fail as follows:
java.util.ServiceConfigurationError:
org.ops4j.pax.exam.TestContainerFactory: Provider
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory
could not be instantiated: java.lang.IllegalStateException: Cannot
select localhost. That usually not a good sign for networking..
at java.util.ServiceLoader.fail(ServiceLoader.java:224)
at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at
org.ops4j.pax.exam.spi.PaxExamRuntime.sanityCheck(PaxExamRuntime.java:172)
at
org.ops4j.pax.exam.spi.PaxExamRuntime.getTestContainerFactory(PaxExamRuntime.java:69)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.createsTestContainerFactory(ReactorManager.java:335)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.createReactor(ReactorManager.java:308)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:80)
at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
at
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.IllegalStateException: Cannot select localhost.
That usually not a good sign for networking..
at
org.ops4j.pax.exam.karaf.container.internal.RMIRegistry.(RMIRegistry.java:51)
at
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory.(KarafTestContainerFactory.java:46)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at java.util.ServiceLoader$LazyIterator.ne

Re: itests (trunk) on Mac osx (now with Java 7)

[Andreas Pieber]

Seams to be probem in RMI remoting. In [1] you find the exception. In [2]
you see a bug which might be connected to it. I only did a VERY short
googling. But this seams to be kind of the problem.

Kind regards,
Andreas

[1]
http://svn.apache.org/repos/asf/karaf/tags/karaf-2.3.0/tooling/exam/container/src/main/java/org/apache/karaf/tooling/exam/container/internal/RMIRegistry.java

[2] http://bugs.sun.com/view_bug.do?bug_id=7166687


On Thu, Dec 5, 2013 at 4:58 PM, David Bosschaert  wrote:

> Hi all,
>
> I have updated to Java 7 on my Mac and am getting the errors below
> with the itests [1]. They work fine for me on Linux. Also note that
> all the other maven modules in karaf trunk test/pass fine for me.
> Anyone an idea? I'm using the following Java:
>   $ java -version
>   java version "1.7.0_45"
>   Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
>   Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
>
> Thanks,
>
> David
>
> [1] All the itests fail as follows:
> java.util.ServiceConfigurationError:
> org.ops4j.pax.exam.TestContainerFactory: Provider
> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory
> could not be instantiated: java.lang.IllegalStateException: Cannot
> select localhost. That usually not a good sign for networking..
> at java.util.ServiceLoader.fail(ServiceLoader.java:224)
> at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
> at
> org.ops4j.pax.exam.spi.PaxExamRuntime.sanityCheck(PaxExamRuntime.java:172)
> at
> org.ops4j.pax.exam.spi.PaxExamRuntime.getTestContainerFactory(PaxExamRuntime.java:69)
> at
> org.ops4j.pax.exam.spi.reactors.ReactorManager.createsTestContainerFactory(ReactorManager.java:335)
> at
> org.ops4j.pax.exam.spi.reactors.ReactorManager.createReactor(ReactorManager.java:308)
> at
> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
> at
> org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:80)
> at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
> at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.IllegalStateException: Cannot select localhost.
> That usually not a good sign for networking..
> at
> org.ops4j.pax.exam.karaf.container.internal.RMIRegistry.(RMIRegistry.java:51)
> at
> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory.(KarafTestContainerFactory.java:46)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:374)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
> ... 31 more
>

Re: A Blueprint Free Karaf

[Achim Nierbeck]

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 

> 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é  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é 
> >>
> >>> 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 
> 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. 
> >
> >  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 

Re: itests (trunk) on Mac osx (now with Java 7)

[Jean-Baptiste Onofré]

Hi David,

I'm working on it as the itests fail on Linux (with Java7) too.

It should be fixed soon.

Regards
JB

On 12/05/2013 04:58 PM, David Bosschaert wrote:

Hi all,

I have updated to Java 7 on my Mac and am getting the errors below
with the itests [1]. They work fine for me on Linux. Also note that
all the other maven modules in karaf trunk test/pass fine for me.
Anyone an idea? I'm using the following Java:
   $ java -version
   java version "1.7.0_45"
   Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
   Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Thanks,

David

[1] All the itests fail as follows:
java.util.ServiceConfigurationError:
org.ops4j.pax.exam.TestContainerFactory: Provider
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory
could not be instantiated: java.lang.IllegalStateException: Cannot
select localhost. That usually not a good sign for networking..
at java.util.ServiceLoader.fail(ServiceLoader.java:224)
at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at org.ops4j.pax.exam.spi.PaxExamRuntime.sanityCheck(PaxExamRuntime.java:172)
at 
org.ops4j.pax.exam.spi.PaxExamRuntime.getTestContainerFactory(PaxExamRuntime.java:69)
at 
org.ops4j.pax.exam.spi.reactors.ReactorManager.createsTestContainerFactory(ReactorManager.java:335)
at 
org.ops4j.pax.exam.spi.reactors.ReactorManager.createReactor(ReactorManager.java:308)
at 
org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:80)
at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at 
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
at 
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.IllegalStateException: Cannot select localhost.
That usually not a good sign for networking..
at 
org.ops4j.pax.exam.karaf.container.internal.RMIRegistry.(RMIRegistry.java:51)
at 
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory.(KarafTestContainerFactory.java:46)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
... 31 more



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

itests (trunk) on Mac osx (now with Java 7)

[David Bosschaert]

Hi all,

I have updated to Java 7 on my Mac and am getting the errors below
with the itests [1]. They work fine for me on Linux. Also note that
all the other maven modules in karaf trunk test/pass fine for me.
Anyone an idea? I'm using the following Java:
  $ java -version
  java version "1.7.0_45"
  Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
  Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Thanks,

David

[1] All the itests fail as follows:
java.util.ServiceConfigurationError:
org.ops4j.pax.exam.TestContainerFactory: Provider
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory
could not be instantiated: java.lang.IllegalStateException: Cannot
select localhost. That usually not a good sign for networking..
at java.util.ServiceLoader.fail(ServiceLoader.java:224)
at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at org.ops4j.pax.exam.spi.PaxExamRuntime.sanityCheck(PaxExamRuntime.java:172)
at 
org.ops4j.pax.exam.spi.PaxExamRuntime.getTestContainerFactory(PaxExamRuntime.java:69)
at 
org.ops4j.pax.exam.spi.reactors.ReactorManager.createsTestContainerFactory(ReactorManager.java:335)
at 
org.ops4j.pax.exam.spi.reactors.ReactorManager.createReactor(ReactorManager.java:308)
at 
org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:80)
at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at 
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
at 
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.IllegalStateException: Cannot select localhost.
That usually not a good sign for networking..
at 
org.ops4j.pax.exam.karaf.container.internal.RMIRegistry.(RMIRegistry.java:51)
at 
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory.(KarafTestContainerFactory.java:46)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
... 31 more

Re: A Blueprint Free Karaf

[Johan Edstrom]

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é  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é 
>> 
>>> 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  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. 
> 
>  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é > 
>>> 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
>>

Re: A Blueprint Free Karaf

[Jean-Baptiste Onofré]

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  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. 


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é 
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 

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 bet

Re: A Blueprint Free Karaf

[Jean-Baptiste Onofré]

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é 


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  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. 


  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é 
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 


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

Re: A Blueprint Free Karaf

[Daniel Kulp]

On Dec 5, 2013, at 10:32 AM, 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?

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é 
> 
>> 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  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. 
 
 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é  
>> 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 

Re: A Blueprint Free Karaf

[Achim Nierbeck]

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é 

> 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  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. 
>>>
>>>  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é >>>
> 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 
>>>
>>> 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 t

Re: A Blueprint Free Karaf

[Daniel Kulp]

On Dec 5, 2013, at 7: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.

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. 
> 
>> 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é >> 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 
> 
> 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 rea

Re: A Blueprint Free Karaf

[Ioannis Canellos]

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

[Christian Schneider]

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. 


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é 
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 

  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,

Re: A Blueprint Free Karaf

[Hadrian Zbarcea]

+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. 


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é 
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 

  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 

Re: A Blueprint Free Karaf

[Jamie G.]

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  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. 
>
> > 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é  > >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 
> > >>>
> > >>>  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.
> >

Re: A Blueprint Free Karaf

[Guillaume Nodet]

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. 

> 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é  >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 
> >>>
> >>>  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
> > bluepri

Re: A Blueprint Free Karaf

[Jamie G.]

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é 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 
>>>
>>>  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

Re: A Blueprint Free Karaf

[Jean-Baptiste Onofré]

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 


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 

Re: A Blueprint Free Karaf

[Ioannis Canellos]

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

[Christian Schneider]

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 


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

Re: A Blueprint Free Karaf

[Jean-Baptiste Onofré]

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 


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

Re: A Blueprint Free Karaf

[Guillaume Nodet]

2013/12/5 Christian Schneider 

> 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

[Christian Schneider]

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

[Achim Nierbeck]

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 

> @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  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: A Blueprint Free Karaf

[Ioannis Canellos]

@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

[Ehsan Zaery Moghaddam]

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é 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 
>>
>>  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 >>
 wrote:

>>>
>>>  Guillaume,

 that's why I would go for 4.0 :)

 regards, Achim


 2013/12/5 Guillaume Nodet 

  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 
>
>  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_jen...@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 
>>>
>> 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 

Re: A Blueprint Free Karaf

[Jean-Baptiste Onofré]

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 


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 
wrote:



Guillaume,

that's why I would go for 4.0 :)

regards, Achim


2013/12/5 Guillaume Nodet 


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 


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_jen...@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 

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  Committer & PMC
OPS4J Pax Web  Committer

&

Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 







--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: A Blueprint Free Karaf

[Achim Nierbeck]

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 

> 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 
>
> > 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  > >wrote:
> >
> > > Guillaume,
> > >
> > > that's why I would go for 4.0 :)
> > >
> > > regards, Achim
> > >
> > >
> > > 2013/12/5 Guillaume Nodet 
> > >
> > > > 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 
> > > >
> > > > > 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_jen...@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  >
> > > > 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:
> > > 

Re: A Blueprint Free Karaf

[Guillaume Nodet]

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 

> 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  >wrote:
>
> > Guillaume,
> >
> > that's why I would go for 4.0 :)
> >
> > regards, Achim
> >
> >
> > 2013/12/5 Guillaume Nodet 
> >
> > > 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 
> > >
> > > > 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_jen...@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 
> > > 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)
> 

Re: A Blueprint Free Karaf

[Achim Nierbeck]

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 

> 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 
>
> > 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 
> >
> > > 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"  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é 
> > > >
> > > > > 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é
> > > > > jbono...@apache.org
> > > > > http://blog.nanthrax.net
> > > > > Talend - http://www.talend.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Apache Karaf  Committer & PMC
> > > > OPS4J Pax Web 
> > Committer
> > > &
> > > > Project Lead
> > > > OPS4J Pax for Vaadin <
> > http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
> > > > Commiter & Project Lead
> > > > blog 

Re: A Blueprint Free Karaf

[Andreas Pieber]

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 wrote:

> Guillaume,
>
> that's why I would go for 4.0 :)
>
> regards, Achim
>
>
> 2013/12/5 Guillaume Nodet 
>
> > 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 
> >
> > > 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  > > >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 
> > 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  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> OPS4J Pax for Vaadin 
> Commiter & Project Lead
> blog 
>

Re: A Blueprint Free Karaf

[Achim Nierbeck]

Guillaume,

that's why I would go for 4.0 :)

regards, Achim


2013/12/5 Guillaume Nodet 

> 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 
>
> > 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  > >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 
> 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  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: A Blueprint Free Karaf

[Guillaume Nodet]

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 

> 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 
>
> > 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"  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é 
> > >
> > > > 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é
> > > > jbono...@apache.org
> > > > http://blog.nanthrax.net
> > > > Talend - http://www.talend.com
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Apache Karaf  Committer & PMC
> > > OPS4J Pax Web 
> Committer
> > &
> > > Project Lead
> > > OPS4J Pax for Vaadin <
> http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
> > > Commiter & Project Lead
> > > blog 
> > >
> >
>
>
>
> --
>
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> OPS4J Pax for Vaadin 
> Commiter & Project Lead
> blog 
>

Re: A Blueprint Free Karaf

[Jean-Baptiste Onofré]

+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 


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"  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é 


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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com





--

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer

&

Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 









--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: A Blueprint Free Karaf

[Guillaume Nodet]

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 

> 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  >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  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

[Achim Nierbeck]

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 

> 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"  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é 
> >
> > > 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é
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
> >
> >
> >
> > --
> >
> > Apache Karaf  Committer & PMC
> > OPS4J Pax Web  Committer
> &
> > Project Lead
> > OPS4J Pax for Vaadin 
> > Commiter & Project Lead
> > blog 
> >
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Custom PersistenceManager for Config Admin

[Kevin Cox]

Hi,
Much like this post, I am interested in creating a custom PersistenceManager
for Config Admin.
http://karaf.922171.n3.nabble.com/Custom-PersistenceManager-tp4028050.html

Is there a way to replace the PersistenceManager from Felix with my own, or
do I need to create a custom Config Admin implementation (based on Felix's)? 
I would want to remove/stop the default Felix PersistenceManager and replace
its functionality altogether.

I can see the packaging from Felix in these files and I've read the source,
but an approach is not clear to me.

etc/startup.properties:
org/apache/felix/org.apache.felix.configadmin/1.6.0/org.apache.felix.configadmin-1.6.0.jar=10

system/org/apache/karaf/assemblies/features/standard/2.3.3/standard-2.3.3-features.xml:
mvn:org.apache.felix/org.apache.felix.configadmin/1.6.0

Thanks,
Kevin



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Custom-PersistenceManager-for-Config-Admin-tp4030530.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: A Blueprint Free Karaf

[Andreas Pieber]

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"  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é 
>
> > 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é
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
>
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> OPS4J Pax for Vaadin 
> Commiter & Project Lead
> blog 
>