Hi Serge, GraalVM Native is interesting, but keeping the OSGi internals it will be a bit challenging (especially regarding reflections). I don't say it's impossible, but it's more work/challenges.
Regards JB On Wed, Jun 5, 2024 at 3:13 PM Serge Huber <bhil...@gmail.com> wrote: > > Hi JB thanks for the proposal, > > Sounds great to me. For me Karaf 5 should really be a natural fit for > containerized deployments, making it super easy to package applications > that can then easily be scaled up (and down), so making it more predictable > and possibly more static can be a good thing. > > Is a goal also to make it compatible with GraalVM Native Image ? > > Best regards, > Serge. > > On Tue, Jun 4, 2024 at 11:18 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > Hi folks, > > > > I think it's time to prepare a new milestone for the project :) > > > > Short term (and first step) is to prepare the coming release: > > > > 1. Apache Karaf 4.4.7 will be submitted to vote next week. It will include: > > * Improvement on the spring features repository (providing both > > Spring 5 and Spring 6 features) > > * Dependencies updates and minor fixes found on the 4.4.6 release > > > > 2. Apache Karaf 4.5.0 will be submitted to vote by the end of the > > month. It will include (mainly): > > * New spec features repository with Jakarta specs > > * Bigger fixes for 4.5.0 > > > > 3. Apache Karaf 5.0.0 > > That's the big milestone, and I propose to have big and opinionated > > changes here. OSGi is an implementation detail of the runtime, still > > exposed to the experimented users. > > Be opinionated means that I propose to remove PAX * dependencies, > > and provide Karaf services instead, very simple and opinionated (for > > instance, instead of PAX Web, a simple Tomcat based service, instead > > of PAX Logging, a simple slf4j/log4j only service, Pax Exam replaced > > by JUnit 5 simple extensions, etc). > > Another goal of Karaf 5 is to bring new tooling to improve dev > > experience (annotation based distributions generation, etc). > > Also, users will be able to smoothly deploy Spring powered or > > Servlet applications without knowing/leveraging OSGi (especially the > > import/export pattern). > > > > Thoughts ? > > > > Regards > > JB > >
