Hello pon., 4 mar 2019 o 17:58 Serge Huber <[email protected]> napisał(a):
> 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. > Felix-Connect (formerly known as PojoSR) is a single classloader base and osgi registry. It can run some scenarios, for example there's camel-test-blueprint framework, but some bundles simply don't work there - for example Aries JPA (at least it didn't work last time we've checked). So I agree. Build time resolution (and long etc/startup.properties - all features as <startupFeatures>), static configadmin, reference: URIs, so they're read directly from system/ (not populating data/cache/). But single classloader is a bit against OSGi ;) regards Grzegorz Grzybek > > 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 > > >
