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 <[email protected]> wrote: > +1 > > Am Mo., 4. März 2019 um 15:29 Uhr schrieb Guillaume Nodet < > [email protected] > >: > > > 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é <[email protected]> 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é <[email protected]> > 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é > > > >> [email protected] > > > >> http://blog.nanthrax.net > > > >> Talend - http://www.talend.com > > > >> > > > > > > > > > > > > > > -- > > > Jean-Baptiste Onofré > > > [email protected] > > > http://blog.nanthrax.net > > > Talend - http://www.talend.com > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com >
