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:29:01 GMT
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

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