karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [PROPOSAL] Introduce "static" resolver
Date Mon, 04 Mar 2019 15:27:25 GMT
I agree. The static profile already works great by doing the resolution on
build time.

Actually it is the same model that bnd resolve also uses. They just do not
have the feature concept and only rely on a set of repositories.

Christian

Am Mo., 4. März 2019 um 15:15 Uhr schrieb Guillaume Nodet <gnodet@apache.org
>:

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


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

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