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 17:11:43 GMT
In the demo that I pointed, there's no single classloader, it uses the real
OSGi framework, but there's no resolution of Karaf Features at runtime,
that part is done fully at build time and the runtime just has to install
the bundles that are listed in etc/startup.properties.

Le lun. 4 mars 2019 à 17:58, Serge Huber <shuber@apache.org> a écrit :

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


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

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