You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2014/01/16 10:50:18 UTC
Minimal karaf distro
We recently talked about using Declarative Services for creating a
smaller karaf distro.
I think we could even go farther than that. I think the core of karaf is
the karaf features and pax url. So how about just starting these in the
startup features.
Everything else could be loaded as a feature and so might be optional.
So basically it would mainly be features core, pax url, pax logging +
their dependencies. As blueprint would be overkill for this scenario we
would have to make the features core only use plain OSGi APIs but that
should be doable. Of course such a runtime would have no shell so we
would need to add some way to stop karaf but that should also be doable.
So what would a user get with this compared to plain OSGi? Basically he
would be able to install all the nice existing features for cxf, camel,
.. and also of course his own application, all from a maven repo.
We might also consider the shell to be a core of karaf but I am not sure
it is absolutely necessary.
If you think this is worth pursuing I could make the features core
independent of blueprint and create a proof of concept distro like
described.
What do you think?
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
For example one use case would be to have this as a basis for custom
distros.
Perhaps someone does not like blueprint or the karaf shell. Currently it
is very difficult to create
a custom distro that does not contain one of these.
With a really minimal karaf base distro a user could pick and choose
exactly what he wants. For example if you create a distro for an
embedded device or mobile device.
.. and perhaps even Neil would like such a minimal distro... No that
would go too far as there is still maven involved.
Christian
On 16.01.2014 11:00, Achim Nierbeck wrote:
> At that point I would fully understand Neil Bartles bashing of
> ApplicationServers, why in the world would we need this if a plain
> framework is just enough ...
> Oh wait, the main method for starting is there ...
> Nah, I don't see much of a value of such a stripped server
>
> but that's only my 2 cents ...
>
> regards, Achim
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Achim Nierbeck <bc...@googlemail.com>.
At that point I would fully understand Neil Bartles bashing of
ApplicationServers, why in the world would we need this if a plain
framework is just enough ...
Oh wait, the main method for starting is there ...
Nah, I don't see much of a value of such a stripped server
but that's only my 2 cents ...
regards, Achim
2014/1/16 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Hi Christian,
>
> what's the value of such Karaf distribution compare to OSGi framework
> (felix) with some bundle in it ?
> It's basically just framework + Karaf feature, right ? We don't have
> shell, management, etc.
>
> Do I understand correctly ?
>
> Regards
> JB
>
>
> On 01/16/2014 10:50 AM, Christian Schneider wrote:
>
>> We recently talked about using Declarative Services for creating a
>> smaller karaf distro.
>>
>> I think we could even go farther than that. I think the core of karaf is
>> the karaf features and pax url. So how about just starting these in the
>> startup features.
>> Everything else could be loaded as a feature and so might be optional.
>>
>> So basically it would mainly be features core, pax url, pax logging +
>> their dependencies. As blueprint would be overkill for this scenario we
>> would have to make the features core only use plain OSGi APIs but that
>> should be doable. Of course such a runtime would have no shell so we
>> would need to add some way to stop karaf but that should also be doable.
>>
>> So what would a user get with this compared to plain OSGi? Basically he
>> would be able to install all the nice existing features for cxf, camel,
>> .. and also of course his own application, all from a maven repo.
>>
>> We might also consider the shell to be a core of karaf but I am not sure
>> it is absolutely necessary.
>>
>> If you think this is worth pursuing I could make the features core
>> independent of blueprint and create a proof of concept distro like
>> described.
>>
>> What do you think?
>>
>> Christian
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
I think we all agree that using native OSGi apis for all of karaf is no
good idea.
I only intended to use the native APIs for the feature core bundle. The
setup is definately harder than with DS but it is doable and
allows to have a core ( I think I would even name it bootstrap or
similar) that does not depend on any framework. One advantage would be
that this core would
run with any version of DS and blueprint. If we use one of these
internally we kind of dictate the version as we ship it.
Ideally I would like to see a karaf core or bootstrap that just consists
of two small bundles:
1. Support for mvn urls
2. features core or perhaps in the future subsystems
The system dir of the net distro then only would need to contain these
two bundles + the framework of course.
Of course we are quite far from that but I think it would make sense to
move a bit in the direction of such a simple setup.
Christian
Am 20.01.2014 13:19, schrieb Ioannis Canellos:
>> I had the impression to read an e-mail from Peter Kriens ;)
> LOL
>
>> I know DS interests. My point was more DS or Blueprint vs OSGi "native". It
>> was not between DS and Blueprint.
> Ooops. I think that I misunderstood your question.
>
> The problem with the plain OSGi approach, is that its extremely hard
> to get it done right and really hard to maintain it.
> In the simplest case, you have a service that depends on an other
> service and using a plain service tracker is pretty straight forward.
> When a service has more than one service dependencies the complexity
> starts to increase. You'll need to be extra careful to prevent
> concurrency issues and the resulting code will be hard to deal with
> (tons of boilerplate all over the place).
>
> And of course, transparency and control wise we wouldn't even be as
> near as DS can get us ;-)
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Minimal karaf distro
Posted by Ioannis Canellos <io...@gmail.com>.
> I had the impression to read an e-mail from Peter Kriens ;)
LOL
> I know DS interests. My point was more DS or Blueprint vs OSGi "native". It
> was not between DS and Blueprint.
Ooops. I think that I misunderstood your question.
The problem with the plain OSGi approach, is that its extremely hard
to get it done right and really hard to maintain it.
In the simplest case, you have a service that depends on an other
service and using a plain service tracker is pretty straight forward.
When a service has more than one service dependencies the complexity
starts to increase. You'll need to be extra careful to prevent
concurrency issues and the resulting code will be hard to deal with
(tons of boilerplate all over the place).
And of course, transparency and control wise we wouldn't even be as
near as DS can get us ;-)
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I had the impression to read an e-mail from Peter Kriens ;)
I know DS interests. My point was more DS or Blueprint vs OSGi "native".
It was not between DS and Blueprint.
I agree with your points, and they make sense. I have no problem to
think about this for Karaf 4.0.0, but I would plan tests
(usage/benchmark), etc as it may have an impact for users.
Regards
JB
On 01/20/2014 12:06 PM, Ioannis Canellos wrote:
>> @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 ;)
>
> The value of using DS instead of Blueprint focuses around those areas:
> i) smaller footprint
> ii) proxy free
> iii) improved lifecycle management of components.
> iv) you get metatype metadata for free (less maintenance).
> v) increased control / transparency -> way easier to diagnose issues
> (see scr commands and scr mbeans).
>
> From my point of view the biggest problem with blueprint is that is
> the lacking lifecycle management features of DS.
> So in many cases, we currently register services, commands & mbeans,
> even if the core service required for all those is missing. Then we
> are using proxies or service trackers to wait or check if the service
> is actually there.
> Of course, this is no biggie (other than initializing and registering
> unusable objects) when we know that eventually everything is going to
> be there, but when you want to try to make things as decoupled as
> possible and go for the minimum this can be a problem. Why? because
> you can end up waiting forever on services that wait for a proxy and
> so on.
>
> An other really important point, is that when you are using DS, you
> are able to see and interact with the state of your components, see
> which components have unsatisfied dependencies and how your components
> are wired together. With blueprint everything is a black box.
>
> For these reasons I also feel that it doesn't worth going for a pure
> OSGi api solution, since you gain (i) & (ii) but still loose all the
> others and also have the burden of maintenance.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by Ioannis Canellos <io...@gmail.com>.
> @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 ;)
The value of using DS instead of Blueprint focuses around those areas:
i) smaller footprint
ii) proxy free
iii) improved lifecycle management of components.
iv) you get metatype metadata for free (less maintenance).
v) increased control / transparency -> way easier to diagnose issues
(see scr commands and scr mbeans).
>From my point of view the biggest problem with blueprint is that is
the lacking lifecycle management features of DS.
So in many cases, we currently register services, commands & mbeans,
even if the core service required for all those is missing. Then we
are using proxies or service trackers to wait or check if the service
is actually there.
Of course, this is no biggie (other than initializing and registering
unusable objects) when we know that eventually everything is going to
be there, but when you want to try to make things as decoupled as
possible and go for the minimum this can be a problem. Why? because
you can end up waiting forever on services that wait for a proxy and
so on.
An other really important point, is that when you are using DS, you
are able to see and interact with the state of your components, see
which components have unsatisfied dependencies and how your components
are wired together. With blueprint everything is a black box.
For these reasons I also feel that it doesn't worth going for a pure
OSGi api solution, since you gain (i) & (ii) but still loose all the
others and also have the burden of maintenance.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
@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 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 no Blueprint should be an option.
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
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 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 no Blueprint should be an option.
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Ioannis Canellos <io...@gmail.com>.
@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 no Blueprint should be an option.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
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 prefer.
Christian
On 17.01.2014 10:59, Achim Nierbeck wrote:
> This step forward can only be achieved if we move from blueprint to DS, but
> not
> back to do the plumbing ourselfs.
>
> regards, Achim
>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <io...@gmail.com>
> 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 with different versions/implementations of
> Blueprint etc.
> So this is actually a "step forward".
>
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 ;)
Regards
JB
On 01/17/2014 12:13 PM, Christian Schneider wrote:
> 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 DS. ... I only hope DS does not have similar
> issues :-)
>
> Christian
>
> On 17.01.2014 11:14, Jean-Baptiste Onofré wrote:
>> 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, even if Karaf use Blueprint internally, it doesn't mean that you
>> can't use (from an user perspective) another implementations or
>> framework.
>>
>> Regards
>> JB
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
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 DS. ... I only hope DS does not have similar
issues :-)
Christian
On 17.01.2014 11:14, Jean-Baptiste Onofré wrote:
> 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, even if Karaf use Blueprint internally, it doesn't mean that you
> can't use (from an user perspective) another implementations or
> framework.
>
> Regards
> JB
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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, even if Karaf use Blueprint internally, it doesn't mean that you
can't use (from an user perspective) another implementations or framework.
Regards
JB
On 01/17/2014 10:55 AM, Ioannis Canellos wrote:
> 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 with different versions/implementations of
> Blueprint etc.
> So this is actually a "step forward".
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by Ioannis Canellos <io...@gmail.com>.
>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 with different versions/implementations of
Blueprint etc.
So this is actually a "step forward".
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 have a question: how many users/people use CXF DOSGi outside of
Karaf (so directly in Felix or Equinox without Blueprint) ?
I just think loud. I think core/minimal/net distributions make sense
(and I already created Jira and started to work on it).
I just wonder about "breaking" feature implementation to remove the
blueprint dependency. Don't get me wrong, I'm not against, I just wonder
the benefit for end users.
I'm still thinking about this.
Regards
JB
On 01/17/2014 10:10 AM, Christian Schneider wrote:
> 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 DOSGi we went the same road. It used blueprint before
> and we switched to plain OSGi API so people have maximum freedom how to
> use DSOGi. There it costs even a little more as we have more setup than
> feature core does.
>
> Christian
>
> On 17.01.2014 09:54, Achim Nierbeck wrote:
>> 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 if you create a distro for an
>>> embedded
>>> device or mobile device.
>>
>> Unless no one noticed,
>> set advocatus diaboli on:
>>
>> If it's used for internals fine, but do we really need it?
>> What is the benefit of it. I don't see much more value to it
>> then what Ioannis already did propose for the minimal distribution.
>> It'll skip blueprint as you propose and as far as I can estimate "Neil"
>> would love seeing DS as basis ;)
>> (but this is just an assumption, based on observing different mail and
>> stackoverflow threads)
>>
>> set advocatus diaboli off!
>>
>> right now I'd stick to the idea of Ioannis with a minimal distribution
>> based on DS.
>> This should be sufficient and will keep the hassles of Trackers away.
>>
>> regards, Achim
>>
>>
>>
>>
>>
>> 2014/1/17 Christian Schneider <ch...@die-schneider.net>
>>
>>> 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
>>> distros.
>>> For example if we do not include aries blueprint in framework people can
>>> use their prefered version of blueprint. Currently upgrades of blueprint
>>> are always tie to a change off the karaf version.
>>>
>>> At the same time providing the current standard and minimal distros will
>>> not become more difficult as we would just move some bundles from
>>> startup.properties into features. Like Ioannis wrote it is just a way to
>>> make karaf more modular.
>>>
>>> We still can provide a core distro if people see value in it but it
>>> is not
>>> my main concern to have this.
>>>
>>> So if we can agree that a framework feature without blueprint would make
>>> sense I will try to make features core independent of blueprint. This
>>> should not affect any other modules and gives us the basis for a slimmer
>>> framework kar.
>>>
>>> Christian
>>>
>>>
>>> On 16.01.2014 21:39, Achim Nierbeck wrote:
>>>
>>>> Hi Ioannis,
>>>>
>>>> no trouble with this kind of "minimal" cause it gives a real value
>>>> on top
>>>> of
>>>> the OSGi framework. Otherwise I wouldn't know where the difference is
>>>> between
>>>> using a plain OSGi framework + pax-url and Karaf.
>>>>
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>> 2014/1/16 Ioannis Canellos <io...@gmail.com>
>>>>
>>>> If the distribution only starts framework, config admin, scr &
>>>> pax-url
>>>>> & karaf features, then minimal = net.
>>>>>
>>>>> --
>>>>> Ioannis Canellos
>>>>>
>>>>> Blog: http://iocanel.blogspot.com
>>>>> Twitter: iocanel
>>>>>
>>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
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 DOSGi we went the same road. It used blueprint before
and we switched to plain OSGi API so people have maximum freedom how to
use DSOGi. There it costs even a little more as we have more setup than
feature core does.
Christian
On 17.01.2014 09:54, Achim Nierbeck wrote:
> 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 if you create a distro for an embedded
>> device or mobile device.
>
> Unless no one noticed,
> set advocatus diaboli on:
>
> If it's used for internals fine, but do we really need it?
> What is the benefit of it. I don't see much more value to it
> then what Ioannis already did propose for the minimal distribution.
> It'll skip blueprint as you propose and as far as I can estimate "Neil"
> would love seeing DS as basis ;)
> (but this is just an assumption, based on observing different mail and
> stackoverflow threads)
>
> set advocatus diaboli off!
>
> right now I'd stick to the idea of Ioannis with a minimal distribution
> based on DS.
> This should be sufficient and will keep the hassles of Trackers away.
>
> regards, Achim
>
>
>
>
>
> 2014/1/17 Christian Schneider <ch...@die-schneider.net>
>
>> 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 distros.
>> For example if we do not include aries blueprint in framework people can
>> use their prefered version of blueprint. Currently upgrades of blueprint
>> are always tie to a change off the karaf version.
>>
>> At the same time providing the current standard and minimal distros will
>> not become more difficult as we would just move some bundles from
>> startup.properties into features. Like Ioannis wrote it is just a way to
>> make karaf more modular.
>>
>> We still can provide a core distro if people see value in it but it is not
>> my main concern to have this.
>>
>> So if we can agree that a framework feature without blueprint would make
>> sense I will try to make features core independent of blueprint. This
>> should not affect any other modules and gives us the basis for a slimmer
>> framework kar.
>>
>> Christian
>>
>>
>> On 16.01.2014 21:39, Achim Nierbeck wrote:
>>
>>> Hi Ioannis,
>>>
>>> no trouble with this kind of "minimal" cause it gives a real value on top
>>> of
>>> the OSGi framework. Otherwise I wouldn't know where the difference is
>>> between
>>> using a plain OSGi framework + pax-url and Karaf.
>>>
>>>
>>> regards, Achim
>>>
>>>
>>> 2014/1/16 Ioannis Canellos <io...@gmail.com>
>>>
>>> If the distribution only starts framework, config admin, scr & pax-url
>>>> & karaf features, then minimal = net.
>>>>
>>>> --
>>>> Ioannis Canellos
>>>>
>>>> Blog: http://iocanel.blogspot.com
>>>> Twitter: iocanel
>>>>
>>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 if you create a distro for an embedded
> device or mobile device.
Unless no one noticed,
set advocatus diaboli on:
If it's used for internals fine, but do we really need it?
What is the benefit of it. I don't see much more value to it
then what Ioannis already did propose for the minimal distribution.
It'll skip blueprint as you propose and as far as I can estimate "Neil"
would love seeing DS as basis ;)
(but this is just an assumption, based on observing different mail and
stackoverflow threads)
set advocatus diaboli off!
right now I'd stick to the idea of Ioannis with a minimal distribution
based on DS.
This should be sufficient and will keep the hassles of Trackers away.
regards, Achim
2014/1/17 Christian Schneider <ch...@die-schneider.net>
> 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 distros.
> For example if we do not include aries blueprint in framework people can
> use their prefered version of blueprint. Currently upgrades of blueprint
> are always tie to a change off the karaf version.
>
> At the same time providing the current standard and minimal distros will
> not become more difficult as we would just move some bundles from
> startup.properties into features. Like Ioannis wrote it is just a way to
> make karaf more modular.
>
> We still can provide a core distro if people see value in it but it is not
> my main concern to have this.
>
> So if we can agree that a framework feature without blueprint would make
> sense I will try to make features core independent of blueprint. This
> should not affect any other modules and gives us the basis for a slimmer
> framework kar.
>
> Christian
>
>
> On 16.01.2014 21:39, Achim Nierbeck wrote:
>
>> Hi Ioannis,
>>
>> no trouble with this kind of "minimal" cause it gives a real value on top
>> of
>> the OSGi framework. Otherwise I wouldn't know where the difference is
>> between
>> using a plain OSGi framework + pax-url and Karaf.
>>
>>
>> regards, Achim
>>
>>
>> 2014/1/16 Ioannis Canellos <io...@gmail.com>
>>
>> If the distribution only starts framework, config admin, scr & pax-url
>>> & karaf features, then minimal = net.
>>>
>>> --
>>> Ioannis Canellos
>>>
>>> Blog: http://iocanel.blogspot.com
>>> Twitter: iocanel
>>>
>>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
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 distros. For example if we do not include aries blueprint in
framework people can use their prefered version of blueprint. Currently
upgrades of blueprint are always tie to a change off the karaf version.
At the same time providing the current standard and minimal distros will
not become more difficult as we would just move some bundles from
startup.properties into features. Like Ioannis wrote it is just a way to
make karaf more modular.
We still can provide a core distro if people see value in it but it is
not my main concern to have this.
So if we can agree that a framework feature without blueprint would make
sense I will try to make features core independent of blueprint. This
should not affect any other modules and gives us the basis for a slimmer
framework kar.
Christian
On 16.01.2014 21:39, Achim Nierbeck wrote:
> Hi Ioannis,
>
> no trouble with this kind of "minimal" cause it gives a real value on top of
> the OSGi framework. Otherwise I wouldn't know where the difference is
> between
> using a plain OSGi framework + pax-url and Karaf.
>
>
> regards, Achim
>
>
> 2014/1/16 Ioannis Canellos <io...@gmail.com>
>
>> If the distribution only starts framework, config admin, scr & pax-url
>> & karaf features, then minimal = net.
>>
>> --
>> Ioannis Canellos
>>
>> Blog: http://iocanel.blogspot.com
>> Twitter: iocanel
>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Ioannis,
no trouble with this kind of "minimal" cause it gives a real value on top of
the OSGi framework. Otherwise I wouldn't know where the difference is
between
using a plain OSGi framework + pax-url and Karaf.
regards, Achim
2014/1/16 Ioannis Canellos <io...@gmail.com>
> If the distribution only starts framework, config admin, scr & pax-url
> & karaf features, then minimal = net.
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Re: Minimal karaf distro
Posted by Ioannis Canellos <io...@gmail.com>.
If the distribution only starts framework, config admin, scr & pax-url
& karaf features, then minimal = net.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
I would even leave out scr and implement features core with pure OSGi APIs.
Of course we could still refactor all other modules to scr but I think
it makes sense to
not depend on any DI framework in the core.
Christian
On 16.01.2014 15:52, Ioannis Canellos wrote:
> Well, the minimal distribution we have "was always meant" to be the
> minimum possible distro, that could allow everything else to start via
> features. So I am 100% aligned with Christian on this.
>
> The only reason that the minimal distribution does not look like this
> already, is that it has been a bit painful to isolate and decouple
> parts of Karaf from each other.
>
> So the minimal distro could just be: osgi framework + config admin +
> scr + pax-url + karat features.
>
> In my demo branch (https://github.com/iocanel/karaf/tree/karaf-light)
> it looks like this with the addition of shell, but that can be made
> optional too.
>
> @Achim: Even though I see real value in such a thin server . The real
> value comes from making Karaf so modular that it makes the extremely
> thin server possible ;-) Don't forget that we are building a runtime
> for modular applications, making the runtime itself modular is a must
> imho.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I agree, but be careful with the wording: now, I'm pretty sure that the
users don't consider the minimal distribution as you do.
That's why I would prefer core, net, minimal.
My only concern is: do you think it's really expected by users. I mean,
net and minimal could be interesting for users, but core. We can always
do it, but I wonder if it's really helpful for the users.
My 0.02$
I'm still thinking about that ;)
Regards
JB
On 01/16/2014 03:52 PM, Ioannis Canellos wrote:
> Well, the minimal distribution we have "was always meant" to be the
> minimum possible distro, that could allow everything else to start via
> features. So I am 100% aligned with Christian on this.
>
> The only reason that the minimal distribution does not look like this
> already, is that it has been a bit painful to isolate and decouple
> parts of Karaf from each other.
>
> So the minimal distro could just be: osgi framework + config admin +
> scr + pax-url + karat features.
>
> In my demo branch (https://github.com/iocanel/karaf/tree/karaf-light)
> it looks like this with the addition of shell, but that can be made
> optional too.
>
> @Achim: Even though I see real value in such a thin server . The real
> value comes from making Karaf so modular that it makes the extremely
> thin server possible ;-) Don't forget that we are building a runtime
> for modular applications, making the runtime itself modular is a must
> imho.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by Ioannis Canellos <io...@gmail.com>.
Well, the minimal distribution we have "was always meant" to be the
minimum possible distro, that could allow everything else to start via
features. So I am 100% aligned with Christian on this.
The only reason that the minimal distribution does not look like this
already, is that it has been a bit painful to isolate and decouple
parts of Karaf from each other.
So the minimal distro could just be: osgi framework + config admin +
scr + pax-url + karat features.
In my demo branch (https://github.com/iocanel/karaf/tree/karaf-light)
it looks like this with the addition of shell, but that can be made
optional too.
@Achim: Even though I see real value in such a thin server . The real
value comes from making Karaf so modular that it makes the extremely
thin server possible ;-) Don't forget that we are building a runtime
for modular applications, making the runtime itself modular is a must
imho.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
That sounds good. My term of minimal was a bit misleading perhaps as I
did not mean to replace the "minimal" distro we have now.
Core might be a better word for it. Of course we would need to also put
some disclaimer on the description of core as it is not very accessible
or usable without a little customization.
I also think we need to work a bit on pax url to see if it can be made
smaller (mostly regarding the number of bundles). I have seen some
discussions on the ops4j lists that go in the same direction.
Christian
On 16.01.2014 11:26, Jean-Baptiste Onofré wrote:
> I see.
>
> If I compare with starting directly from the OSGi framework, I can see
> the following values:
> - abstraction of the OSGi framework (supporting both Felix and Equinox)
> - Pax URL by default (to support various type of URL)
> - Karaf features (to extend the distribution)
>
> Am I right ?
>
> If we use the "Linux distribution wording", I would propose:
> - Karaf core (as you propose)
> - Karaf net (a "lightweight" distribution bootstrapped with an
> Internet connection)
> - Karaf minimal (like the net one but with all embedded in the system
> repository)
> - Karaf (the "complete" distribution)
>
> Does it make sense ? Not sure ;) I have to think about that a bit.
>
> Regards
> JB
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I see.
If I compare with starting directly from the OSGi framework, I can see
the following values:
- abstraction of the OSGi framework (supporting both Felix and Equinox)
- Pax URL by default (to support various type of URL)
- Karaf features (to extend the distribution)
Am I right ?
If we use the "Linux distribution wording", I would propose:
- Karaf core (as you propose)
- Karaf net (a "lightweight" distribution bootstrapped with an Internet
connection)
- Karaf minimal (like the net one but with all embedded in the system
repository)
- Karaf (the "complete" distribution)
Does it make sense ? Not sure ;) I have to think about that a bit.
Regards
JB
On 01/16/2014 11:08 AM, Christian Schneider wrote:
> The value is that you can just add any boot features to it that you like.
> It can be your own stuff but it can of course also be the shell,
> management, enterprise features, ...
>
> So basically you start small but can add all of karaf and enterprise
> features you like with just some small change in the config.
>
> Christian
>
> On 16.01.2014 10:57, Jean-Baptiste Onofré wrote:
>> Hi Christian,
>>
>> what's the value of such Karaf distribution compare to OSGi framework
>> (felix) with some bundle in it ?
>> It's basically just framework + Karaf feature, right ? We don't have
>> shell, management, etc.
>>
>> Do I understand correctly ?
>>
>> Regards
>> JB
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by Christian Schneider <ch...@die-schneider.net>.
The value is that you can just add any boot features to it that you like.
It can be your own stuff but it can of course also be the shell,
management, enterprise features, ...
So basically you start small but can add all of karaf and enterprise
features you like with just some small change in the config.
Christian
On 16.01.2014 10:57, Jean-Baptiste Onofré wrote:
> Hi Christian,
>
> what's the value of such Karaf distribution compare to OSGi framework
> (felix) with some bundle in it ?
> It's basically just framework + Karaf feature, right ? We don't have
> shell, management, etc.
>
> Do I understand correctly ?
>
> Regards
> JB
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Christian,
what's the value of such Karaf distribution compare to OSGi framework
(felix) with some bundle in it ?
It's basically just framework + Karaf feature, right ? We don't have
shell, management, etc.
Do I understand correctly ?
Regards
JB
On 01/16/2014 10:50 AM, Christian Schneider wrote:
> We recently talked about using Declarative Services for creating a
> smaller karaf distro.
>
> I think we could even go farther than that. I think the core of karaf is
> the karaf features and pax url. So how about just starting these in the
> startup features.
> Everything else could be loaded as a feature and so might be optional.
>
> So basically it would mainly be features core, pax url, pax logging +
> their dependencies. As blueprint would be overkill for this scenario we
> would have to make the features core only use plain OSGi APIs but that
> should be doable. Of course such a runtime would have no shell so we
> would need to add some way to stop karaf but that should also be doable.
>
> So what would a user get with this compared to plain OSGi? Basically he
> would be able to install all the nice existing features for cxf, camel,
> .. and also of course his own application, all from a maven repo.
>
> We might also consider the shell to be a core of karaf but I am not sure
> it is absolutely necessary.
>
> If you think this is worth pursuing I could make the features core
> independent of blueprint and create a proof of concept distro like
> described.
>
> What do you think?
>
> Christian
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Ioannis,
don't mix both.
The net/minimal/core distro will be included in 3.0.1 without changing
the content.
The second step is for 4.x, but no rush.
Regards
JB
On 02/05/2014 04:15 PM, Ioannis Canellos wrote:
>> I totally agree with you. Do you know, if your work on this task will be
>> very huge? and when do you think, than end user could be use this new karaf?
>> (just to have an idea !)
>
> It requires a couple of man days for the core.
> And almost the same amount of time for the commands. Now if we could
> create an annotation processor that would help reducing the annotation
> boilerplate in commands it could take a little less.
>
> This has been scheduled for 4.x. I don't know when 4.x is planned.
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by Ioannis Canellos <io...@gmail.com>.
> I totally agree with you. Do you know, if your work on this task will be
> very huge? and when do you think, than end user could be use this new karaf?
> (just to have an idea !)
It requires a couple of man days for the core.
And almost the same amount of time for the commands. Now if we could
create an annotation processor that would help reducing the annotation
boilerplate in commands it could take a little less.
This has been scheduled for 4.x. I don't know when 4.x is planned.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Minimal karaf distro
Posted by xav <xa...@eaton.com>.
all,
good news, for our project, it's will very useful
regards
--
View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031551.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I plan to cleanup and provide new distros for Karaf 3.0.1 (I created the
Jira, and I have local git branches on which I'm working on).
In term of deadline, I'm busy on 2.3.4 release this week. We can plan
3.0.1 in around 3 weeks.
Regards
JB
On 02/05/2014 03:09 PM, xav wrote:
> Hi JB,
>
> I totally agree with you. Do you know, if your work on this task will be
> very huge? and when do you think, than end user could be use this new karaf?
> (just to have an idea !)
>
>
> Regards
>
> XM
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031532.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by xav <xa...@eaton.com>.
Hi JB,
I totally agree with you. Do you know, if your work on this task will be
very huge? and when do you think, than end user could be use this new karaf?
(just to have an idea !)
Regards
XM
--
View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031532.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Xav,
That's why I propose the first step with net/minimal/core distributions.
But, I think targeting the minimum footprint should not be a final goal.
I mean, of course, we have to be careful on the footprint, but honestly,
look at the footprint now, and look at the features that we provide:
it's not so bad (compare with other containers or application servers ;)).
So, I think we are inline: careful on the footprint, but keep a good
provided features level.
Regards
JB
On 02/05/2014 10:37 AM, xav wrote:
> Hi all,
>
> I discussed with Jean-Batiste and Christian on this subject. Here my point
> of view:
> We use Karaf in my project, to having feature and etc.. But we don't use
> blueprint (we use Ipojo), and one a main goal is: have a application based
> on osgi, and have a footprint minimalist (not more 10 Mo for the OSGI
> container). The problem, now with the karaf distribution, is we took lot of
> bundle for nothing (for my project of course), and the size of my
> application is very large, and it's a big problem for me.
>
> Regards
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031526.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by xav <xa...@eaton.com>.
Hi all,
I discussed with Jean-Batiste and Christian on this subject. Here my point
of view:
We use Karaf in my project, to having feature and etc.. But we don't use
blueprint (we use Ipojo), and one a main goal is: have a application based
on osgi, and have a footprint minimalist (not more 10 Mo for the OSGI
container). The problem, now with the karaf distribution, is we took lot of
bundle for nothing (for my project of course), and the size of my
application is very large, and it's a big problem for me.
Regards
--
View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031526.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Minimal karaf distro
Posted by sekaijin <jy...@yahoo.fr>.
thank you.
I understand
A+JYT
--
View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031341.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
We are inline: Karaf Cave could be used during the construction of the
distribution.
The purpose is to have atomic features, externalized from Karaf
distribution itself.
Regards
JB
On 01/25/2014 03:56 PM, sekaijin wrote:
> Yes this solution is to first install a Karaf base
> for once installed and configured
> deploy over the transverse featrures of entreprise .
> and finally to deploy specific components in the platform .
>
> but in very large distribution company to have a turnkey , that are deployed
> independently is much more efficient.
> Karaf + only the necessaries features + the transverse features of the
> business in one package allows to deploy tens of times.
>
> we have our package deployed 17 times
> the procedure is the maximun simplified.
> untar , run config shell script to fix name and ports and start .
> all users can perform their work.
>
> we dropped a commercial solution for two reasons
> platform contained many useless. thing possible to remove so it required a
> lot of resources to ussage .
> The deployment process was long , complex and expensive .
>
>
> It is a bit like ServiceMix
> If you had for install ServiceMix, install Karaf, then install all the
> elements to run ServiceMix. would require a lot of time before we can define
> its first route.
>
> We see the same thing with Eclipse which allows to define distibutions for a
> particular purpose.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031338.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by sekaijin <jy...@yahoo.fr>.
Yes this solution is to first install a Karaf base
for once installed and configured
deploy over the transverse featrures of entreprise .
and finally to deploy specific components in the platform .
but in very large distribution company to have a turnkey , that are deployed
independently is much more efficient.
Karaf + only the necessaries features + the transverse features of the
business in one package allows to deploy tens of times.
we have our package deployed 17 times
the procedure is the maximun simplified.
untar , run config shell script to fix name and ports and start .
all users can perform their work.
we dropped a commercial solution for two reasons
platform contained many useless. thing possible to remove so it required a
lot of resources to ussage .
The deployment process was long , complex and expensive .
It is a bit like ServiceMix
If you had for install ServiceMix, install Karaf, then install all the
elements to run ServiceMix. would require a lot of time before we can define
its first route.
We see the same thing with Eclipse which allows to define distibutions for a
particular purpose.
--
View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031338.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Minimal karaf distro
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
it's one of the purpose of Karaf Cave: provide an Karaf Features
"Global" Repository. The features are no more embedded into Karaf
directly: Karaf connect to Cave repository providing all features
(likely gathering different feature repositories).
Regards
JB
On 01/25/2014 03:13 PM, sekaijin wrote:
> Hello,
>
> I think the idea of being able to create scalable distributions is
> interresting.
> I defined (version 2.2.2) a distribution, with Karaf core, JPA, JTA, and
> Camel.
> this diistribution is the basis for a solution for my business that adds a
> number of features specific to our business.
> I did not use ServiceMix or Fuse because my need was not to have ESB. not
> need CXF NMR etc..
>
> To achieve this distribution with version 2.2.2,I had to completely replace
> the featrues defined in Karaf. Karaf base and Karaf enterprise was
> unsuitable.
>
> in this discussion, you talk about :
> - Karaf core (as you propose)
> - Karaf net (a "lightweight" distribution bootstrapped with an Internet
> connection)
> - Karaf minimal (like the net one but with all embedded in the system
> repository)
> - Karaf (the "complete" distribution)
>
> If we create some "package" like Database, JNDI, Transaction, etc.. in
> different featrues files. and not in karaf enterprise, we open the
> possibility of to create custom distributions that take one or more package
> for specific uses based on Karaf core, Karaf net or Karaf minimal. the full
> distribution is only the sum of the other.
>
> today my distribution is not based on anything. Because Karaf base (2.2.2)
> contains elements that I had to withdraw.
>
> A+JYT
> PS sorry for my approximative english.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031336.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Minimal karaf distro
Posted by sekaijin <jy...@yahoo.fr>.
Hello,
I think the idea of being able to create scalable distributions is
interresting.
I defined (version 2.2.2) a distribution, with Karaf core, JPA, JTA, and
Camel.
this diistribution is the basis for a solution for my business that adds a
number of features specific to our business.
I did not use ServiceMix or Fuse because my need was not to have ESB. not
need CXF NMR etc..
To achieve this distribution with version 2.2.2,I had to completely replace
the featrues defined in Karaf. Karaf base and Karaf enterprise was
unsuitable.
in this discussion, you talk about :
- Karaf core (as you propose)
- Karaf net (a "lightweight" distribution bootstrapped with an Internet
connection)
- Karaf minimal (like the net one but with all embedded in the system
repository)
- Karaf (the "complete" distribution)
If we create some "package" like Database, JNDI, Transaction, etc.. in
different featrues files. and not in karaf enterprise, we open the
possibility of to create custom distributions that take one or more package
for specific uses based on Karaf core, Karaf net or Karaf minimal. the full
distribution is only the sum of the other.
today my distribution is not based on anything. Because Karaf base (2.2.2)
contains elements that I had to withdraw.
A+JYT
PS sorry for my approximative english.
--
View this message in context: http://karaf.922171.n3.nabble.com/Minimal-karaf-distro-tp4031073p4031336.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.