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 19:48:09 GMT
You get me wrong.

There are actually two proposal:

1. Static distribution/resolution build time. We already have all ready,
just documentation and adding example.
2. Single classloader is winegrower. It's NOT karaf, but it brings all
Karaf features. That's a second discussion.

So, just to be clear, I'm moving forward on 1 right now and we will have
a dedicated thread about winegrower.

Regards
JB

On 04/03/2019 17:58, Serge Huber wrote:
> I also like the proposed solution using build-time generation.
> 
> Just a question about the single classloader though: isn't that going to
> cause problems if projects want to use different versions of a library? I
> agree that they shouldn't but it's also something that makes Karaf more
> powerful than Spring in general.
> 
> Regards,
>   Serge...
> 
> On Mon, Mar 4, 2019 at 4:28 PM Christian Schneider <chris@die-schneider.net>
> wrote:
> 
>> +1
>>
>> Am Mo., 4. März 2019 um 15:29 Uhr schrieb Guillaume Nodet <
>> gnodet@apache.org
>>> :
>>
>>> 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
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Computer Scientist
>> http://www.adobe.com
>>
> 

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

Mime
View raw message