Yes, the demo I would like to add is: - starting from user code - use the generate-features goal to create the features XML - use the generated features XML as static distribution - add jib plugin to directly create the docker image based on the distribution
It would be a great starting point to show how to use Karaf for the cloud/docker/kubernetes. Regards JB On 04/03/2019 15:29, Guillaume Nodet wrote: > 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 >> > > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
