Hi To be clear about Karaf 4.5.0: the plan is not to change the internals. You will still be able to use OSGi specs / services.
The main proposed change is to simplify the services in Karaf mostly for the pax * parts. There are two main reasons about that : - having Karaf provided services would simplify the releases, dependency management and security due diligence - some pax components are very complex and we can have a simpler impl (and maintainable) with Karaf opiniated service Specifically about pax web, it doesn’t mean necessary to not super OSGi web spec. It’s mainly to focus on tomcat and Karaf impl as part of the Karaf project. I hope it helps regards JB Le mer. 5 juin 2024 à 07:06, Bernd Eckenfels <e...@zusammenkunft.net> a écrit : > I am looking forward to a lighter solution if it > Brings us JakartaEE and less overhead. > > However there is a lot of flexibility and work in > those PAX projects, you sure you can replicate > them? > > (Things like providing and configuring all > common logging Fassaden are just one of the > perks we like about Karaf) > > Also when you say PAX Exam replacement, will you still provide the test > APIs to setup framework and bundles and how does that affect the runtime. > Or maybe the other way around - does that only affect how Karaf 5 is tested > but not what users will use? > > (BTW I was not following closely, is this „karaf 5“ then the new named > runtime or a step in between? I’d there still a Codename for it? > > Personally speaking I am not happy about > migrating to a new environment, If I would be I > might as well consider spring boot or one of the > micro service projects with big econsystens - especially if even the Felix > and PAX Ecosystem > no longer would be first class providers) > > The 447/45 plans sound great, though. > > Gruß > Bernd > > > fpapon wrote on 5. June 2024 06:46 (GMT +02:00): > > > Hi, > > > > I already discuss with JB (at community over code Bratislava) about > > these points so I have nothing to add :) > > > > Just keeping in mind that we want to have a lighter project for the > > maintainability and abstract the OSGi complexity. > > > > regards, > > > > François > > > > On 04/06/2024 11:17, Jean-Baptiste Onofré 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 > > > > -- > > -- > > François > > > > > > > Gruß > Bernd > — > https://bernd.eckenfels.net >
