GitHub user death-knight opened a pull request:
https://github.com/apache/karaf/pull/23
[KARAF-1972] Fixing the scope handing of the karaf-maven-plugin
Here is a fix the bahavior mentioned in:
https://issues.apache.org/jira/browse/KARAF-1972
You can merge this pull request into a G
You mean footprint in terms of what ? memory or filesystem ?
Actually both, but mostly filesystem, not that much in terms of memory.
Regarding the issue in blueprint (some are related to the
implementation, not the blueprint spec itself), I'm afraid we will have
similar issues in DS ;)
Regard
@Ioannis: agree, but I wonder the value of using DS instead of
Blueprint, or the "overwork plumbing" to use pure OSGi insteand of DS or
Blueprint ;)
On 01/17/2014 12:23 PM, Ioannis Canellos wrote:
@Achim: I don't fancy plumbing myself.
@Chrisitan: Let's make one step at the time: Replace Bluep
Sounds good.
Is it ok if I convert the features core to DS as a starting point?
Christian
On 17.01.2014 12:23, Ioannis Canellos wrote:
@Achim: I don't fancy plumbing myself.
@Chrisitan: Let's make one step at the time: Replace Blueprint with DS
and then we can consider if it worths turning to p
@Achim: I don't fancy plumbing myself.
@Chrisitan: Let's make one step at the time: Replace Blueprint with DS
and then we can consider if it worths turning to pure OSGi APIs (just
for the feature service).
@Jean Baptiste: Agree, but still it doesn't mean that we have to use
one or the other, using
That is correct. Using blueprint does not block the user from using
other frameworks but blueprint has a quite big foot print. It has
several jars itself and also needs aries proxy. Besides that we had a
lot of blueprint or proxy related issues recently. So I really see a
benefit of changing to
I fully agree. Moving from blueprint to OSGi APIs for all of karaf would
be a big step back.
For the features core alone it might be different. It depends on how
much we want to bind ourselfs to DS. As DS has a much smaller footprint
than Blueprint I am ok to even keep it in the core if you pr
Hi Ioannis,
Good point, but, for instance, if Karaf requires Aries Blueprint (only
for the namespace handler), it doesn't mean that we can't use another
Blueprint implementation (like Gemini). Pushing namespace handlers out
of the topic, it's already possible to use Gemini instead of Aries.
So
This step forward can only be achieved if we move from blueprint to DS, but
not
back to do the plumbing ourselfs.
regards, Achim
2014/1/17 Ioannis Canellos
> From my point of view blueprint is fine. It does simplify things a lot
> and our users do use it. That doesn't mean that Karaf needs to
>From my point of view blueprint is fine. It does simplify things a lot
and our users do use it. That doesn't mean that Karaf needs to use it
too.
Decoupling Karaf from blueprint, not only allows Karaf to have a
smaller footprint, but also allows provides more flexibility since
Karaf could be used
It's funny: blueprint has been designed to simplify the implementation,
and now, it seems that "we want" move backward.
Of course, we can use Activator, ServiceTracker, directly ConfigAdmin:
on one side you remove a dependency (to blueprint), on another side you
write more plumbing.
Now, I hav
I am fine with switching to DS in general. Still I think it should make
sense to have the innermost core of karaf even independent from DS.
It does not cost us a lot as we only will have one module without DS and
gives people a little more freedom about what they can do.
For example in CXF DOSG
Ahh, that gives a better picture.
Cause the headline of this thread just suggest building another distro
"Minimal Karaf distro", and till now you've always argued about a
minimal/core distro.
With a really minimal karaf base distro a user could pick and choose
> exactly what he wants. For example
Hi Achim,
I am aware that the core "distro" is rather not meant to be downloaded
and used as is by users. I rather think it could replace the current
"framework" feature that we and others use to build distros. With a
slimmer framework kar we give people more freedom on how to assemble
their
14 matches
Mail list logo
