karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Papon <francois.pa...@openobject.fr>
Subject Re: [PROPOSAL] Introduce "static" resolver
Date Mon, 04 Mar 2019 17:24:48 GMT
Fully agree about the "missing" part, we have to focuse on tooling and
documentation because most of the time, end users doesn't know the
capabilities or how to deal with.


François Papon

Le 04/03/2019 à 18:18, Jean-Baptiste Onofré a écrit :
> That's a very good argument and actually I think you are right, that's
> even better.
> Maybe the "missing" part if the tooling and the documentation around this.
> Let me prepare a PR for that !
> Regards
> JB
> On 04/03/2019 15:15, Guillaume Nodet wrote:
>> I would argue that we should not use any resolver at all for such
>> containers, and that's already doable with the karaf plugin.
>> We have a demo of that in the
>>   examples/karaf-profile-example/karaf-profile-example-static
>> The resolution is done at build time and the list of bundles is written in
>> the
>>   etc/startup.properties
>> file, by virtue of having the features configured at startup phase rather
>> than boot phase.
>> In this demo, we even avoid the fact that felix usually copy the bundles in
>> its internal storage by using startup bundles referenced as:
>>   reference\:file\:org/ops4j/pax/logging/pax-logging-api/1.10.1/pax-logging-api-1.10.1.jar
>> = 8
>> This leads to no resolution at all at runtime (the example assembly does
>> not even contain the karaf features service), a much faster startup time,
>> less disk space used.
>> Unless I'm mistaken, I don't really see the need to build another different
>> thing, but maybe I missed something.
>> Guillaume
>> Le lun. 4 mars 2019 à 15:00, Jean-Baptiste Onofré <jb@nanthrax.net> a
>> écrit :
>>> Hi guys,
>>> During the introduction thread about "kloud initiative", we quickly
>>> discussed about the resolver.
>>> Today, we can see concerns about the current features resolver, especially:
>>> - the resolution at runtime can be different than the one done during
>>> verify
>>> - the resolution at runtime can be impacted by the version range
>>> - the resolution can cause bunch of refresh, impacting startup and
>>> resolution time
>>> If the current resolver is great for a "container/dynamic" approach
>>> where karaf is running and we deploy things in it, it's not good for a
>>> "static" bootstrapping as expected for a runtime running on cloud or
>>> docker.
>>> I would like to propose to introduce a feature resolver named "karaf".
>>> The idea is to use a resolver that reads the features repositories as
>>> they are and install bundles/configuration/etc without checking all
>>> capabilities and requirements. It sounds a bit like a mix of the simple
>>> resolver we use in the Karaf maven plugin in the verify goal, and what
>>> we had in the past (in Karaf 2.x for instance). It doesn't perform any
>>> refresh, it's up to the developer (and of course the tooling) to provide
>>> a complete features definition.
>>> The resolver could be configured in etc/org.apache.karaf.features.cfg
>>> and we can have a "static" distribution with this resolver by default.
>>> I would propose to rename "standard" distribution as "container", and we
>>> will provide the "static" distribution.
>>> Thoughts ?
>>> Another idea around this is Karaf Winegrower. Winegrower is kind of
>>> Karaf Boot, using a single/unique classloader instead of one classloader
>>> per bundle. It's pretty convenient for cloud as well.
>>> Maybe we can have winegrower as Karaf subproject.
>>> Currently Winegrower is here: https://github.com/jbonofre/winegrower
>>> Thoughts ?
>>> Regards
>>> JB
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com

View raw message