The only limitation - but also to be light and native friendly - is to not use embed jar so some karaf stuff is not compatible and will not to reach graal stage. However rest is compatible and afaik console, ssh, jaxrs whiteboard, etc run well.
Im not sure i would go heavy to stay cloud friendly by default (cronjob and deployment) but we can always enhance the plugin to support cepage from features + jar sorting at build time (graph resolution) for ex, think it can solve most of it staying on the core values (light, cloud, stateless, standalone or embeddable). Hope it makes sense. Le sam. 19 févr. 2022 à 02:22, Bernd Eckenfels <e...@zusammenkunft.net> a écrit : > Yes winegrower can be a good base, it seems customary for Karaf to build > on those technologies. It would somehow be good if the build uses the same > feature and maven infrastructure and when the prerequisites are also used > with karaf binaries (shell and client command as well as a karaf cli). > > I haven’t tried how compatible it would be with Karaf/Gogo commands yet. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > ________________________________ > Von: Romain Manni-Bucau <rmannibu...@gmail.com> > Gesendet: Tuesday, February 8, 2022 1:12:14 PM > An: dev <dev@karaf.apache.org> > Betreff: Re: Karaf 5 shell and native > > Hi, > > I thought winegrower was the one targetting native support by design - and > already has its arthur knight > https://geronimo.apache.org/arthur/winegrower-knight.html - and Karaf 5 > the opposite: aggregation and optimization of heterogeneous runtimes in a > single JVM. > Did I miss anything? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le mar. 8 févr. 2022 à 13:09, Łukasz Dywicki <l...@code-house.org> a > écrit : > > > I did have some small attempts turning basic apps into native images and > > I believe it is very good idea, yet I am not sure if Karaf (or OSGi per > > say) is ready for that. I am glad you are opening this topic as I am > > interested in anyone succeeded in making a native image which can keep > > OSGi semantics. ;-) > > I think problem with native images lies somewhere else than command line > > handling, as we rely on jansi and jline which are used in other > > ecosystems which are deep in native compilation. > > Because Karaf stuff is promoting modulith approach you might have > > multiple apps and services running at the same time. This means that > > native compilation might be more complicated as some of classes will > > obviously get shared across multiple places, the asynchronous nature of > > service activation might result in scenarios where you simply have to > > "warm up" app long enough so you catch all places which are touched by > > java reflection api. Its also possible that without valid preparation > > you will be pulling some libraries in different versions. I am not sure > > how graal is handling that. Given that even netty could produce troubles > > with native image I am a little bit afraid how verbose is preparation > > for more complicated applications. > > > > Best, > > Łukasz > > > > On 7.02.2022 08:14, Bernd Eckenfels wrote: > > > Hello, > > > > > > I wonder are there any plans for native image and tree shaking for > > karaf5? > > > > > > Especially I think we need a shell framework (like quarkus/picocli) > > which allows a fast stand-alone cli. At least if karaf plans to play in > > this space. I like the OSGi console command abstraction, so it would be a > > good candidate if one can proceed to write (Developer and ops) commands > > this way and then compile it. > > > > > > This could even abstract away some of the more arcane to use maven > steps > > (archetype) and add new things like development server or even client.sh. > > > > > > Gruss > > > Bernd > > > > > > > > > -- > > > http://bernd.eckenfels.net > > > > > >
