+1 Am Mo., 4. März 2019 um 15:29 Uhr schrieb Guillaume Nodet <gno...@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é <j...@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é <j...@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é > > >> jbono...@apache.org > > >> http://blog.nanthrax.net > > >> Talend - http://www.talend.com > > >> > > > > > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@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
