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:36:31 GMT
Yes, the demo I would like to add is:

- starting from user code
- use the generate-features goal to create the features XML
- use the generated features XML as static distribution
- add jib plugin to directly create the docker image based on the

It would be a great starting point to show how to use Karaf for the


On 04/03/2019 15:29, Guillaume Nodet wrote:
> Right, and also, the demo is using profiles, and I think we should have a
> demo using plain features instead.  That does not really change anything,
> as the assembly is all done by the plugin, but this lead to a simpler demo.
> Le lun. 4 mars 2019 à 15:18, Jean-Baptiste Onofré <jb@nanthrax.net> 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
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message