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 h
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.
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
>
> W
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 anot
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:
checkInteractionOfHttpAndAr
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.pac
> 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
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 re
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 PO
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
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 everyon
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]
yo
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/contain
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
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 n
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"
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 giv
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,
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 thi
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
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.
>
> Ioa
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 almos
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
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
O
+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,
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
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
t
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 distinguis
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 p
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 t
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
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 a
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
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 real
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
@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
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
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
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 u
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 h
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 th
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
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.
>
>
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
+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 Pie
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 ver
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
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 implem
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 o
49 matches
Mail list logo
