Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
That's true, and that's why it's opinionated :) The purpose is really to match 90% of the use cases. I think some features are interesting but require a lot of effort/maintenance for only a limited use. Regards JB On Thu, Jun 20, 2024 at 9:47 AM Grzegorz Grzybek wrote: > > Thanks for clarification JB! > > Just one more comment about: > > Tomcat for the Karaf Web service yes (not strong opinion here, it > > would be Jetty). And as state earlier, only Servlet/Filter service > > registration package will be supported. > > > That's quite arbitrary distinction TBH :) You know - we rarely write > servlets these days and rather have some kind of dispatcher servlet (yes, > this is spring...) which delegates to different views/controllers/handlers > etc. > However the point is that even if you DO write servlets, then: > >- servlets have access to ServletContext >- ServletContext gives you access to context attributes >- context attributes are either taken from web.xml () or >are setup in ServletContextListeners >- ServletContextListeners are 3rd "big thing" (next to servlets and >filters) that constitute web applications >- so you have to allow them too >- but ServletContextListeners allow you to dynamically register >additional servlets (that's what most SCIs do too - JSF, JSP, ...) >dynamically with dynamic mapping >- also servlets and filters may be protected - in web.xml you can have > and elements... > > I could continue (I've already mentioned JSPs, SCIs, ...) getting closer > and closer to full Servlet API specification... > > The point is that if you want servlets + filters only, you'd need full > implementation based on particular runtime (whether Tomcat, Jetty or > Undertow) to deal with its specifics (like Jetty's ServletContextHandler, > Tomcat's StandardContext or Undertow's DeploymentInfo). You also have to > deal with contexts (implementations of jakarta.servlet.ServletContext > interface) to separate servlets. Though Felix-Http has one "dispatcher > servlet" registered in single context and moves "context" concept from the > runtime to this servlet... > > Anyway - a lot of work ;) > > regards > Grzegorz Grzybek > > czw., 20 cze 2024 o 08:51 Jean-Baptiste Onofré napisał(a): > > > Hi Grzegorz > > > > Thanks for your message, it's highly appreciated. > > > > See my comments inline: > > > > > 1. What exactly are "Karaf services"? Are these OSGi services? > > (registered > > > with BundleContext.registerService(iface, object, properties)?) If not > > then > > > what are the aspects that make them "services" - discoverability, > > > interface, registration method (through annotations and build time > > > processing? /META-INF/services? other?)? > > > > It's OSGi services. > > > > > > > > 2. Removing Pax + hiding OSGi seems complementary, but is OSGi going to > > be > > > implementation detail of Karaf 5? or just deployment method (Minho / > > Felix > > > Atomos?) If you say that pax-web will still be available, it means it > > needs > > > full OSGi runtime (Felix, Equinox) underneath. Mind that the biggest > > > obstacle when refactoring Pax Web 7 into Pax Web 8 was this entire > > > "discoverability" mechanism, which allows you to scan > > > bundles/fragments/wires looking for annotated web elements, SCIs and > > > web-fragment.xml files... So if you hide OSGi under "Karaf services" and > > at > > > the same time keep OSGi for those who want it, it'd be (sorry for > > analogy) > > > like hiding an elephant under a napkin... :) > > > > Fair comment. The purpose of Karaf Services is to simplify and focus > > only on what matters for the users in the Karaf context. > > For instance, why not just supporting Servlet OSGi services listening, > > not need to support annotation web elements or web-fragments.xml. > > If a user wants these features, then it will use Pax Web. > > But, if the user just need a simple webcontainer for servlet and Karaf > > webconsole, then Karaf Web service would be enough. > > > > > > > > 3. Pax URL and Pax Web accept configuration via ConfigAdmin. So again - > > you > > > can't remove, you have to hide it (see #2). > > > > I'm not too concerned about ConfigAdmin: it will stay there. > > > > > > > > 4. Also for Pax Web - it required a lot of effort to make it > > "restartable". > > > I mean even Tomcat/Jetty/Undertow itself keep each webapp in separate > > > classloader, so you can kind of get rid of the webapp (undeploy) if you > > > like. Pax Web pushes this to the extreme with whiteboard, where you can > > > have filters from different bundles filtering access to servlets from > > > different bundles and sending events to listeners from yet different > > > bundles and everything is (should be) classloader-safe. Hinding it under > > > non-hierarchical classloader may not be possible... > > > > Same here: restartable could be Pax Web feature. > > > > > > > > 5. You've mentioned "main focus on Tomcat", but roughly speaking, Tomcat
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Thanks for clarification JB! Just one more comment about: Tomcat for the Karaf Web service yes (not strong opinion here, it > would be Jetty). And as state earlier, only Servlet/Filter service > registration package will be supported. That's quite arbitrary distinction TBH :) You know - we rarely write servlets these days and rather have some kind of dispatcher servlet (yes, this is spring...) which delegates to different views/controllers/handlers etc. However the point is that even if you DO write servlets, then: - servlets have access to ServletContext - ServletContext gives you access to context attributes - context attributes are either taken from web.xml () or are setup in ServletContextListeners - ServletContextListeners are 3rd "big thing" (next to servlets and filters) that constitute web applications - so you have to allow them too - but ServletContextListeners allow you to dynamically register additional servlets (that's what most SCIs do too - JSF, JSP, ...) dynamically with dynamic mapping - also servlets and filters may be protected - in web.xml you can have and elements... I could continue (I've already mentioned JSPs, SCIs, ...) getting closer and closer to full Servlet API specification... The point is that if you want servlets + filters only, you'd need full implementation based on particular runtime (whether Tomcat, Jetty or Undertow) to deal with its specifics (like Jetty's ServletContextHandler, Tomcat's StandardContext or Undertow's DeploymentInfo). You also have to deal with contexts (implementations of jakarta.servlet.ServletContext interface) to separate servlets. Though Felix-Http has one "dispatcher servlet" registered in single context and moves "context" concept from the runtime to this servlet... Anyway - a lot of work ;) regards Grzegorz Grzybek czw., 20 cze 2024 o 08:51 Jean-Baptiste Onofré napisał(a): > Hi Grzegorz > > Thanks for your message, it's highly appreciated. > > See my comments inline: > > > 1. What exactly are "Karaf services"? Are these OSGi services? > (registered > > with BundleContext.registerService(iface, object, properties)?) If not > then > > what are the aspects that make them "services" - discoverability, > > interface, registration method (through annotations and build time > > processing? /META-INF/services? other?)? > > It's OSGi services. > > > > > 2. Removing Pax + hiding OSGi seems complementary, but is OSGi going to > be > > implementation detail of Karaf 5? or just deployment method (Minho / > Felix > > Atomos?) If you say that pax-web will still be available, it means it > needs > > full OSGi runtime (Felix, Equinox) underneath. Mind that the biggest > > obstacle when refactoring Pax Web 7 into Pax Web 8 was this entire > > "discoverability" mechanism, which allows you to scan > > bundles/fragments/wires looking for annotated web elements, SCIs and > > web-fragment.xml files... So if you hide OSGi under "Karaf services" and > at > > the same time keep OSGi for those who want it, it'd be (sorry for > analogy) > > like hiding an elephant under a napkin... :) > > Fair comment. The purpose of Karaf Services is to simplify and focus > only on what matters for the users in the Karaf context. > For instance, why not just supporting Servlet OSGi services listening, > not need to support annotation web elements or web-fragments.xml. > If a user wants these features, then it will use Pax Web. > But, if the user just need a simple webcontainer for servlet and Karaf > webconsole, then Karaf Web service would be enough. > > > > > 3. Pax URL and Pax Web accept configuration via ConfigAdmin. So again - > you > > can't remove, you have to hide it (see #2). > > I'm not too concerned about ConfigAdmin: it will stay there. > > > > > 4. Also for Pax Web - it required a lot of effort to make it > "restartable". > > I mean even Tomcat/Jetty/Undertow itself keep each webapp in separate > > classloader, so you can kind of get rid of the webapp (undeploy) if you > > like. Pax Web pushes this to the extreme with whiteboard, where you can > > have filters from different bundles filtering access to servlets from > > different bundles and sending events to listeners from yet different > > bundles and everything is (should be) classloader-safe. Hinding it under > > non-hierarchical classloader may not be possible... > > Same here: restartable could be Pax Web feature. > > > > > 5. You've mentioned "main focus on Tomcat", but roughly speaking, Tomcat > > operates on entire webapps. It's only Pax Web (or Felix HTTP with Jetty) > > that make it possible to operate on the level of single > > servlet/filter/listener/SCI/... - how could such "Karaf web service for > > Tomcat" look like if you, say, wanted to register a servlet + filter? How > > would you package and register such servlet + filter? > > Tomcat for the Karaf Web service yes (not strong opinion here, it > would be Jetty). And as state earlier, only Servlet/Filter
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hi Grzegorz Thanks for your message, it's highly appreciated. See my comments inline: > 1. What exactly are "Karaf services"? Are these OSGi services? (registered > with BundleContext.registerService(iface, object, properties)?) If not then > what are the aspects that make them "services" - discoverability, > interface, registration method (through annotations and build time > processing? /META-INF/services? other?)? It's OSGi services. > > 2. Removing Pax + hiding OSGi seems complementary, but is OSGi going to be > implementation detail of Karaf 5? or just deployment method (Minho / Felix > Atomos?) If you say that pax-web will still be available, it means it needs > full OSGi runtime (Felix, Equinox) underneath. Mind that the biggest > obstacle when refactoring Pax Web 7 into Pax Web 8 was this entire > "discoverability" mechanism, which allows you to scan > bundles/fragments/wires looking for annotated web elements, SCIs and > web-fragment.xml files... So if you hide OSGi under "Karaf services" and at > the same time keep OSGi for those who want it, it'd be (sorry for analogy) > like hiding an elephant under a napkin... :) Fair comment. The purpose of Karaf Services is to simplify and focus only on what matters for the users in the Karaf context. For instance, why not just supporting Servlet OSGi services listening, not need to support annotation web elements or web-fragments.xml. If a user wants these features, then it will use Pax Web. But, if the user just need a simple webcontainer for servlet and Karaf webconsole, then Karaf Web service would be enough. > > 3. Pax URL and Pax Web accept configuration via ConfigAdmin. So again - you > can't remove, you have to hide it (see #2). I'm not too concerned about ConfigAdmin: it will stay there. > > 4. Also for Pax Web - it required a lot of effort to make it "restartable". > I mean even Tomcat/Jetty/Undertow itself keep each webapp in separate > classloader, so you can kind of get rid of the webapp (undeploy) if you > like. Pax Web pushes this to the extreme with whiteboard, where you can > have filters from different bundles filtering access to servlets from > different bundles and sending events to listeners from yet different > bundles and everything is (should be) classloader-safe. Hinding it under > non-hierarchical classloader may not be possible... Same here: restartable could be Pax Web feature. > > 5. You've mentioned "main focus on Tomcat", but roughly speaking, Tomcat > operates on entire webapps. It's only Pax Web (or Felix HTTP with Jetty) > that make it possible to operate on the level of single > servlet/filter/listener/SCI/... - how could such "Karaf web service for > Tomcat" look like if you, say, wanted to register a servlet + filter? How > would you package and register such servlet + filter? Tomcat for the Karaf Web service yes (not strong opinion here, it would be Jetty). And as state earlier, only Servlet/Filter service registration package will be supported. The purpose is not to remove Pax * projects, it's more to have very simple "native" Karaf services. Regards JB > > Not that I don't approve the plans (I like how you think about the future), > or maybe simply my mind went numb after working for few weeks with > rollup.js and typescript, but I don't feel like I can provide any > constructive feedback besides asking for clarification... > > kind regards > Grzegorz Grzybek > > wt., 11 cze 2024 o 16:20 Matt Pavlovich napisał(a): > > > Hi JB- > > > > Makes sense, I figured I’d make the pitch for the pax-* merger in that > > there is a lot of good use cases, stability and performance scenarios > > already handled there. > > > > I look forward to assisting with the new karaf-* services. > > > > Thanks, > > Matt Pavlovich > > > > > On Jun 11, 2024, at 3:45 AM, Jean-Baptiste Onofré > > wrote: > > > > > > Hi all, > > > > > > I would like to clarify the PAX * questions. It would be still > > > possible to use PAX * projects in Karaf 5.x, via the features (as > > > today), but optional (not boot features anymore). > > > > > > As an alternative, we will have opinionated Karaf services features. > > > > > > For instance, pax-web will still be available (if people want to use > > > it), but Karaf will provide a web feature (as alternative). > > > > > > For URL and logging, Karaf will provide simplified mvn and wrap url > > > handlers, and opinionated Karaf logging service (only supporting slf4j > > > and log4j2). If users still want to use Pax URL and Pax Logging, they > > > will still be able to do so via custom distribution. > > > > > > The reasons to provide Karaf opinionated services are: > > > 1. Karaf services are governed by the ASF rule, as Karaf, which is not > > > the case for Pax > > > 2. Pax * projects are great as "generic" OSGi services. On the other > > > hand, it brings some complexity to be abstract enough for OSGi use > > > cases and compliant with the OSGi specs. Karaf services will really be > > > Karaf
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hello Sorry for late response, I'm stuck in savage and obscure world of JavaScript right now (webpack module federation). Looking back at OSGi, it's seen as clear, pleasant and predictable environment ;) anyway - here are my comments to JB's proposal: 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). > 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. > For instance, pax-web will still be available (if people want to use > it), but Karaf will provide a web feature (as alternative). > > For URL and logging, Karaf will provide simplified mvn and wrap url > handlers, and opinionated Karaf logging service (only supporting slf4j > and log4j2). If users still want to use Pax URL and Pax Logging, they > will still be able to do so via custom distribution. > I have few questions, concerns about the above... 1. What exactly are "Karaf services"? Are these OSGi services? (registered with BundleContext.registerService(iface, object, properties)?) If not then what are the aspects that make them "services" - discoverability, interface, registration method (through annotations and build time processing? /META-INF/services? other?)? 2. Removing Pax + hiding OSGi seems complementary, but is OSGi going to be implementation detail of Karaf 5? or just deployment method (Minho / Felix Atomos?) If you say that pax-web will still be available, it means it needs full OSGi runtime (Felix, Equinox) underneath. Mind that the biggest obstacle when refactoring Pax Web 7 into Pax Web 8 was this entire "discoverability" mechanism, which allows you to scan bundles/fragments/wires looking for annotated web elements, SCIs and web-fragment.xml files... So if you hide OSGi under "Karaf services" and at the same time keep OSGi for those who want it, it'd be (sorry for analogy) like hiding an elephant under a napkin... :) 3. Pax URL and Pax Web accept configuration via ConfigAdmin. So again - you can't remove, you have to hide it (see #2). 4. Also for Pax Web - it required a lot of effort to make it "restartable". I mean even Tomcat/Jetty/Undertow itself keep each webapp in separate classloader, so you can kind of get rid of the webapp (undeploy) if you like. Pax Web pushes this to the extreme with whiteboard, where you can have filters from different bundles filtering access to servlets from different bundles and sending events to listeners from yet different bundles and everything is (should be) classloader-safe. Hinding it under non-hierarchical classloader may not be possible... 5. You've mentioned "main focus on Tomcat", but roughly speaking, Tomcat operates on entire webapps. It's only Pax Web (or Felix HTTP with Jetty) that make it possible to operate on the level of single servlet/filter/listener/SCI/... - how could such "Karaf web service for Tomcat" look like if you, say, wanted to register a servlet + filter? How would you package and register such servlet + filter? Not that I don't approve the plans (I like how you think about the future), or maybe simply my mind went numb after working for few weeks with rollup.js and typescript, but I don't feel like I can provide any constructive feedback besides asking for clarification... kind regards Grzegorz Grzybek wt., 11 cze 2024 o 16:20 Matt Pavlovich napisał(a): > Hi JB- > > Makes sense, I figured I’d make the pitch for the pax-* merger in that > there is a lot of good use cases, stability and performance scenarios > already handled there. > > I look forward to assisting with the new karaf-* services. > > Thanks, > Matt Pavlovich > > > On Jun 11, 2024, at 3:45 AM, Jean-Baptiste Onofré > wrote: > > > > Hi all, > > > > I would like to clarify the PAX * questions. It would be still > > possible to use PAX * projects in Karaf 5.x, via the features (as > > today), but optional (not boot features anymore). > > > > As an alternative, we will have opinionated Karaf services features. > > > > For instance, pax-web will still be available (if people want to use > > it), but Karaf will provide a web feature (as alternative). > > > > For URL and logging, Karaf will provide simplified mvn and wrap url > > handlers, and opinionated Karaf logging service (only supporting slf4j > > and log4j2). If users still want to use Pax URL and Pax
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hi JB- Makes sense, I figured I’d make the pitch for the pax-* merger in that there is a lot of good use cases, stability and performance scenarios already handled there. I look forward to assisting with the new karaf-* services. Thanks, Matt Pavlovich > On Jun 11, 2024, at 3:45 AM, Jean-Baptiste Onofré wrote: > > Hi all, > > I would like to clarify the PAX * questions. It would be still > possible to use PAX * projects in Karaf 5.x, via the features (as > today), but optional (not boot features anymore). > > As an alternative, we will have opinionated Karaf services features. > > For instance, pax-web will still be available (if people want to use > it), but Karaf will provide a web feature (as alternative). > > For URL and logging, Karaf will provide simplified mvn and wrap url > handlers, and opinionated Karaf logging service (only supporting slf4j > and log4j2). If users still want to use Pax URL and Pax Logging, they > will still be able to do so via custom distribution. > > The reasons to provide Karaf opinionated services are: > 1. Karaf services are governed by the ASF rule, as Karaf, which is not > the case for Pax > 2. Pax * projects are great as "generic" OSGi services. On the other > hand, it brings some complexity to be abstract enough for OSGi use > cases and compliant with the OSGi specs. Karaf services will really be > Karaf centric, not necessarily respecting the OSGi specs, but focusing > on users' needs. > 3. Facilitate Karaf tooling around to improve the developer experience. > > Regards > JB > > On Tue, Jun 11, 2024 at 8:48 AM Francois Papon > wrote: >> >> Hi Serge, >> >> You can already build a static Karaf custom definition ready to start >> without downloading all the dependencies at startup and create a docker >> image with that. >> >> The most complex part with GraalVM in our case is all the 3rd party >> dependencies and the OSGi framework. I'm afraid that it will not be >> possible to be GraalVM compatible. >> >> I'm not sure to understand your thoughts about "full OSGi for dev", what >> to you mean? >> >> regards, >> >> François >> >> On 08/06/2024 08:31, Serge Huber wrote: >>> Hi François, >>> >>> I understand not everything has to be native, but for example for Apache >>> Unomi the default deployment is now mostly in containers, and extensions >>> are usually deployed mostly in development environments and then statically >>> packaged for production deployments. >>> >>> Having the option to then use Karaf 5 to leverage the benefits of GraalVM >>> Native Image would be very interesting I believe. I think other >>> applications might be interested in these types of scenarios: full OSGi for >>> development, maybe pre-production and testing, and possibility to have a >>> more « static » deployment for production that could be compatible with >>> native image. >>> >>> WDYT ? >>> >>> Regards, >>>Serge… >>> >>> Le jeu. 6 juin 2024 à 11:09, Francois Papon >>> a écrit : >>> Hi Serge, I don't think there is a benefit about GraalVM for long running process like Karaf. All java things doesn't need to be GraalVM native :) Another problem is that the community edition of GraalVM doesn't bring all the improvement as the commercial one (GC, PGO...) regards, François On 05/06/2024 15:13, Serge Huber 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é > 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 >>
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hi all, I would like to clarify the PAX * questions. It would be still possible to use PAX * projects in Karaf 5.x, via the features (as today), but optional (not boot features anymore). As an alternative, we will have opinionated Karaf services features. For instance, pax-web will still be available (if people want to use it), but Karaf will provide a web feature (as alternative). For URL and logging, Karaf will provide simplified mvn and wrap url handlers, and opinionated Karaf logging service (only supporting slf4j and log4j2). If users still want to use Pax URL and Pax Logging, they will still be able to do so via custom distribution. The reasons to provide Karaf opinionated services are: 1. Karaf services are governed by the ASF rule, as Karaf, which is not the case for Pax 2. Pax * projects are great as "generic" OSGi services. On the other hand, it brings some complexity to be abstract enough for OSGi use cases and compliant with the OSGi specs. Karaf services will really be Karaf centric, not necessarily respecting the OSGi specs, but focusing on users' needs. 3. Facilitate Karaf tooling around to improve the developer experience. Regards JB On Tue, Jun 11, 2024 at 8:48 AM Francois Papon wrote: > > Hi Serge, > > You can already build a static Karaf custom definition ready to start > without downloading all the dependencies at startup and create a docker > image with that. > > The most complex part with GraalVM in our case is all the 3rd party > dependencies and the OSGi framework. I'm afraid that it will not be > possible to be GraalVM compatible. > > I'm not sure to understand your thoughts about "full OSGi for dev", what > to you mean? > > regards, > > François > > On 08/06/2024 08:31, Serge Huber wrote: > > Hi François, > > > > I understand not everything has to be native, but for example for Apache > > Unomi the default deployment is now mostly in containers, and extensions > > are usually deployed mostly in development environments and then statically > > packaged for production deployments. > > > > Having the option to then use Karaf 5 to leverage the benefits of GraalVM > > Native Image would be very interesting I believe. I think other > > applications might be interested in these types of scenarios: full OSGi for > > development, maybe pre-production and testing, and possibility to have a > > more « static » deployment for production that could be compatible with > > native image. > > > > WDYT ? > > > > Regards, > > Serge… > > > > Le jeu. 6 juin 2024 à 11:09, Francois Papon > > a écrit : > > > >> Hi Serge, > >> > >> I don't think there is a benefit about GraalVM for long running process > >> like Karaf. All java things doesn't need to be GraalVM native :) > >> > >> Another problem is that the community edition of GraalVM doesn't bring > >> all the improvement as the commercial one (GC, PGO...) > >> > >> regards, > >> > >> François > >> > >> On 05/06/2024 15:13, Serge Huber 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é > >>> 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
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hi Serge, You can already build a static Karaf custom definition ready to start without downloading all the dependencies at startup and create a docker image with that. The most complex part with GraalVM in our case is all the 3rd party dependencies and the OSGi framework. I'm afraid that it will not be possible to be GraalVM compatible. I'm not sure to understand your thoughts about "full OSGi for dev", what to you mean? regards, François On 08/06/2024 08:31, Serge Huber wrote: Hi François, I understand not everything has to be native, but for example for Apache Unomi the default deployment is now mostly in containers, and extensions are usually deployed mostly in development environments and then statically packaged for production deployments. Having the option to then use Karaf 5 to leverage the benefits of GraalVM Native Image would be very interesting I believe. I think other applications might be interested in these types of scenarios: full OSGi for development, maybe pre-production and testing, and possibility to have a more « static » deployment for production that could be compatible with native image. WDYT ? Regards, Serge… Le jeu. 6 juin 2024 à 11:09, Francois Papon a écrit : Hi Serge, I don't think there is a benefit about GraalVM for long running process like Karaf. All java things doesn't need to be GraalVM native :) Another problem is that the community edition of GraalVM doesn't bring all the improvement as the commercial one (GC, PGO...) regards, François On 05/06/2024 15:13, Serge Huber 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é 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
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hello I'll try to comment in general topic a bit later, but for now, one inline response (below): niedz., 9 cze 2024 o 20:45 Matt Pavlovich napisał(a): > I think this summarizes a core maintenance issue with pax+karaf today > > > I am not sure how many people travel between PAX and Karaf and vice > versa, but lets be honest - contribution criteria for PAX is lower than for > Karaf. > > I suggest we take a look at migrating pax-* (pax-logging. pax-url, > pax-web, etc) into karaf for a couple of practical benefits (perhaps for > Karaf 4.5?): > We had such discussion in 2022: https://lists.apache.org/thread/7oc4opjbplxps9gt8jnr5lxlmtwx0lzh Some time ago, I've moved OPS4J Jira issues to GitHub and I think it improved the release process and community feedback greatly (much easier to create issues and link them with commits). I don't want to sound like an "owner" of Pax Web or Pax Logging, because I only maintain great projects standing on the shoulders of giants. > > 1. Less repositories to manage and preform releases > 2. Artifacts (jars, configs, services) are less confusing to users (ie. > org.apache.karaf.web makes more sense vs org.ops4j.pax.web .. etc) > > This would also give us an opportunity to see how this gels before > finalizing what is supported in Karaf 5 (jetty, tomcat, etc). > Pax Web and Pax Logging would be direct "competitor" to Felix Web and Felix Log and I'm not sure it's good for ASF... But I'm just a plain and simple code maintainer ;) regards Grzegorz Grzybek > > Thoughts? > > Matt Pavlovich
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
I think this summarizes a core maintenance issue with pax+karaf today > I am not sure how many people travel between PAX and Karaf and vice versa, > but lets be honest - contribution criteria for PAX is lower than for Karaf. I suggest we take a look at migrating pax-* (pax-logging. pax-url, pax-web, etc) into karaf for a couple of practical benefits (perhaps for Karaf 4.5?): 1. Less repositories to manage and preform releases 2. Artifacts (jars, configs, services) are less confusing to users (ie. org.apache.karaf.web makes more sense vs org.ops4j.pax.web .. etc) This would also give us an opportunity to see how this gels before finalizing what is supported in Karaf 5 (jetty, tomcat, etc). Thoughts? Matt Pavlovich
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hello, To be fair, I am a bit surprised by idea of dropping pax projects, because this is the area where Karaf as a project, have at least slight chance to share workload with other OSGi users. I agree, that pax-exam is burden, and it doesn't fit very well to JUnit 5. I've made an attempt to port some portions of its logic to junit 5 extension, but many parts of its bootstrap logic is written in very specific way, which reflects junit 4 philosophy. For that reason I completely abandoned testing with pax-exam and switched to test-containers [1]. Coming back to pax issue - OSGi is not most popular stack, having even small amount of work shared with others helps to keep projects going. I am not sure how many people travel between PAX and Karaf and vice versa, but lets be honest - contribution criteria for PAX is lower than for Karaf. I am really not sure what benefit we can bring to people, who prefer running other tech stacks. Given that other ecosystems are much bigger (spring / jee / servlet), often more complex, we will need to accommodate their complexities into Karaf. Making hibernate, spring-aop and so on load time waving is never ending source of troubles with OSGi class loaders. Can we make this complex issue less trouble with OSGi? While we might pretend that we can, and that it will open window of opportunity to grow community, I personally doubt it will ever happen. OSGi is best suited for systems which needs plugins running within single JVM process. If someone's use case happens outside of these boundaries, costs caused by investment in OSGi often will outweigh final profits. I do believe that serving community we have is fair, cause what profit we could give people who wish to run a servlet? Will we make it simpler than Tomcat or Jetty? Or spring-boot? Application development model shifted so much that even application servers struggle to keep their community. I am afraid, that staying inline with principles of OSGi, will make it even less probable. If someone insist to run other stack he can always pick a WAR which will get isolated from OSGi. Or Karaf Minho which promised to bring solution for modulith. Without doubt, there are certain complexities embedded in pax projects (logging, web, jdbc), however many of these come from fairly basic assumptions, such as possibility to swap backing implementation (log4j/logback, jetty/tomcat/undertow), which (I can just suppose) often come out from people who used Karaf. Once we do karaf-logging-log4j, I am quite sure there will be one or two people who will ask about karaf-logging-logback. What we going to do then? These who don't like pax way, might always pick simpler implementations for Apache Felix. All this without dropping osgi, and without our reinventing the wheel. To summarize all above: Lets serve niche we have with tools we made. Best, Łukasz [1] https://github.com/ConnectorIO/connectorio-testcontainers/ On 4.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
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hi François, I understand not everything has to be native, but for example for Apache Unomi the default deployment is now mostly in containers, and extensions are usually deployed mostly in development environments and then statically packaged for production deployments. Having the option to then use Karaf 5 to leverage the benefits of GraalVM Native Image would be very interesting I believe. I think other applications might be interested in these types of scenarios: full OSGi for development, maybe pre-production and testing, and possibility to have a more « static » deployment for production that could be compatible with native image. WDYT ? Regards, Serge… Le jeu. 6 juin 2024 à 11:09, Francois Papon a écrit : > Hi Serge, > > I don't think there is a benefit about GraalVM for long running process > like Karaf. All java things doesn't need to be GraalVM native :) > > Another problem is that the community edition of GraalVM doesn't bring > all the improvement as the commercial one (GC, PGO...) > > regards, > > François > > On 05/06/2024 15:13, Serge Huber 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é > > 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 > >> >
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
Hi Serge, I don't think there is a benefit about GraalVM for long running process like Karaf. All java things doesn't need to be GraalVM native :) Another problem is that the community edition of GraalVM doesn't bring all the improvement as the commercial one (GC, PGO...) regards, François On 05/06/2024 15:13, Serge Huber 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é 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
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
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 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é > 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 > >
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
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é 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 >
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
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 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 >
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
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
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
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
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
On 04/06/2024 11.17 am, Jean-Baptiste Onofré wrote: Hi folks, Hey JB, 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 Awesome. There seem to be a lot of upgrades which are missing in 4.4.6. Random picks from versions:display-dependency-updates show: [INFO] commons-logging:commons-logging ... 1.3.1 -> 1.3.2 [INFO] org.apache.felix:org.apache.felix.cm.json . 1.0.6 -> 2.0.6 [INFO] org.apache.felix:org.apache.felix.configurator .. 1.0.16 -> 1.0.18 [INFO] org.apache.felix:org.apache.felix.http.jetty . 4.2.2 -> 5.1.14 [INFO] org.apache.felix:org.apache.felix.inventory ... 1.1.0 -> 2.0.0 [INFO] org.apache.felix:org.apache.felix.scr 2.2.6 -> 2.2.10 [INFO] org.apache.felix:org.apache.felix.webconsole . 4.8.12 -> 5.0.2 [INFO] org.apache.felix:org.apache.felix.webconsole.plugins.ds ... [INFO] 2.2.0 -> 2.3.0 [INFO] org.apache.felix:org.apache.felix.webconsole.plugins.event ... [INFO] 1.1.8 -> 1.2.0 [INFO] org.apache.felix:org.apache.felix.webconsole.plugins.memoryusage ... [INFO] 1.0.10 -> 1.1.0 [INFO] org.eclipse.platform:org.eclipse.equinox.coordinator ... [INFO] 1.5.200 -> 1.5.300 [INFO] org.eclipse.platform:org.eclipse.equinox.region ... 1.5.300 -> 1.5.500 [INFO] org.eclipse.platform:org.eclipse.osgi ... 3.18.0 -> 3.19.0 [INFO] org.jline:jline . 3.21.0 -> 3.26.1 There probably are a few others. 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 Cool. I am sorry for lack of contributions lately, but there's a ton of stuff requiring my attention downstream. I would hope for karaf-4.5.0 to be strongly opined in terms of: - java-9+ way of doing things - pax-web-9, i.e. servlet-api-4 The former will allow a lot of special-case code to be removed. The latter is actually blocking downstreams from using things like Apache Shiro 2.0.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. Neat. 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). Now that you mention pax-exam, can anyone on this list spin a new release? There's a ton of updates which are not available in a release, like the 'pick a free port' changes, etc. Also, OpenDaylight has a maven plugin to run pax-exam-based validation of a generated feature.xml (see https://github.com/opendaylight/odlparent/tree/master/features-test-plugin) -- would you be interested in having that in karaf.git? 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). Sounds fine for others, but I must say we in OpenDaylight are quite invested in the convenience of dynamic services and their management as offered by Declarative Services (OSGi Compendium chapter 112) and its integration with Config Admin (chapter 104) and Metatype (chapter 105). A sincere, uninformed question: is there anything out there which provides a comparable developer experience? As I mentioned previously, we care about pax-web integration right now, but we expect to move away from it (and related OSGi standards) in very much immediate future (<18 months). I expect we will care about pax-jdbc integration for longer that, unless there is a compelling alternative. Having said that, we are okay to integrate these ourselves, without reliance on Karaf providing them. Regards, Robert OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
+1 (non-binding) on 1 and 2 Some questions/comments about 3 (still non-binding): Unsure about what "no pax web" means for me (OSGi 8 web whiteboard user)? It also feels strange going back to tomcat after all of these years of jetty... but as long as it works I have no strong opinions. One servlet container is as good as any servlet container, I guess...? Also PAX JDBC isn't mentioned there? I'm pretty dependendent on PAX JDBC.
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
1. Sounds good 2. I think Jetty 12 / pax-web support in v4.5.x is important. I started working on a PR for it, but there are significant Jetty API changes. (Jetty 12 support would provide a LTS-like support timeframe while Karaf 5.x gets going.) 3. +1 on JUnit 5 Extension / Runner instead of pax-exam +1 on simplified default logger — One thing pax-logging’s wrapping provides reload of config. Is the thought here to drop runtime reload of logging configuration change?. Regarding replacing pax-web — this seems like a large effort. There are a *ton* of unit tests of various use cases there and lots of value covering a ton of web-deployment scenarios. Are you thinking of dropping http whiteboard or other deploy scenarios in favor of servlet-only? If the other scenarios are required, perhaps keep pax-web and only go wtih Jetty/Tomcat support? I don’t see a lot of demand / usage of Undertow. 4. Configuration and Encryption service (and encryption of config keys and values) as first-class services instead of jasypt add-on. (JDK crypto out-of-the-box). My $0.02. Thanks, Matt Pavlovich > On Jun 4, 2024, at 4:17 AM, 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
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
On Tue, Jun 04, 2024 at 11:17:56AM +0200, 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 Hello, +1 for FIPS Can we also consider the following: 1.) First-class support for Gradle. I have a template project I use for doing custom distributions on top of Karaf I can make available if interested. 2.) A solution/replacement for OSGi security. I'm not sure of the state of things past JDK17. -- Chaz
Re: [PROPOSAL] Apache Karaf runtime releases and roadmap
+1 on points 1 and 2. Point 3: Simplifying developer/operator experience is certainly a great north star for Karaf. Would adding enhanced security such as FIPS mode support be something the community would desire? Cheers, Jamie On Tue, Jun 4, 2024 at 6:48 AM 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
[PROPOSAL] Apache Karaf runtime releases and roadmap
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
