karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [PROPOSAL] Introduce "static" resolver
Date Mon, 04 Mar 2019 14:22:11 GMT
By the way, the only thing missing in the example IMHO is to do all in a
row: code, assembly, jib in one module.

I'm preparing an example using this approach.

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

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

Mime
View raw message