You get me wrong. There are actually two proposal:
1. Static distribution/resolution build time. We already have all ready, just documentation and adding example. 2. Single classloader is winegrower. It's NOT karaf, but it brings all Karaf features. That's a second discussion. So, just to be clear, I'm moving forward on 1 right now and we will have a dedicated thread about winegrower. Regards JB On 04/03/2019 17:58, Serge Huber wrote: > 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 >> > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
