karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [PROPOSAL] Introduce "static" resolver
Date Mon, 04 Mar 2019 14:15:31 GMT
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
>


-- 
------------------------
Guillaume Nodet

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message