karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [PROPOSAL] Introduce "static" resolver
Date Mon, 04 Mar 2019 17:14:59 GMT
Hello guys

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

Well, strictly speaking karaf does not compete with spring (blueprint or ds
could)

 Your point is however valid but with recent OSGi services (whiteboard
pattern often) it is also the case with a plain OSGi container, you just
move the issues somewhere else so rational behind winegrower was to keep
the strength of karaf, its ecosystem, and enable its number one abandon
reason to disappear (OSGi build constraints).

It also enables to use karaf with not OSGi ecosystems and make hybrid apps
which is very powerful.

Last point: it opens the door to graal where osgi will be limited to jlink
;).



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

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