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
