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
