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 > > >
