+1 having pax-web v10 support in Karaf 4.5/5 will also allow users to be able to have a stable fallback while the new Karaf services are coming online and reaching feature parity.
Thanks! > On Feb 26, 2025, at 7:27 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi Grzegorz > > There's no problem about using GH Issues on ASF projects: several > projects are already using that. > Also, the ASF Infra is supporting GitHub Actions (for security > reasons, they are managing the allowed GH Actions > https://infra.apache.org/github-actions-policy.html). > > Yes, as discussed, I think we should avoid any inner <repository/> in > our features repositories. It's way more flexible and allow users to > easily update/manage dependencies. > I'm working on a new PRs about that. > > For Pax Web 10, you do an amazing job, thanks again for that ! > I reinforced what I said in my previous email: Pax *, including Pax > Web, will still be supported and packaged in Karaf. We "just" create a > new distribution with Karaf "core" services. > > Thanks ! > Regards > JB > > On Wed, Feb 26, 2025 at 7:39 AM Grzegorz Grzybek <gr.grzy...@gmail.com> wrote: >> >> Hello >> >> My 2¢ about Pax. I don't have any strong opinion on the plan and I simply >> agree. I was only wondering about ASF governance - is it ok to move >> (fully/partially/automatically/manually) from issues.apache.org to GH? >> >> Now about Pax - as suggested, I see <repository> for pax web is almost >> removed from Karaf standard features ( >> https://github.com/apache/karaf/pull/1934). This makes Karaf distro ready >> to install any features you like regarding web without strong opinion on >> which (pax? felix-http?) is "opinionated" by Karaf. >> >> Pax Web 8 (Jetty 9, Tomcat 9, Undertow 2.2, JDK8+) and 9 (Jetty 10, Tomcat >> 9, Undertow 2.2, JDK11+) are in kind of maintenance mode - I fix issues >> (thanks community!) as they arrive and I try to keep runtimes up to date. >> >> Last week I've rebased my work on Pax Web 10 (Jetty 12, Tomcat 10.1, >> Undertow 2.3, JDK 17+) on top of latest Pax Web 9 and as discussed almost >> all I need is ready: >> >> - OSGi CMPN 8.1 no longer includes "chapter 102: HttpService", so I >> moved this interface to org.ops4j.pax.web.service package - there's no >> other option >> - OSGi CMPN 8.1 chapter 140 (Servlet Whiteboard) is implemented in Pax >> Web 10 - I used it to check if Jolokia 2 (jakarta.servlet based) can be >> whiteboard-registered >> - OSGi CMPN 8.1 chapter 128 (Web Applications) is not updated from >> javax.servlet to jakarta.servlet, but this kind of "special" OSGi CMPN >> specification, because there's no API, only definition of some behaviors >> related to deployment of WARs - and most of the work (OSGi-fying non-OSGi >> WAR archives) is done by Pax URL 3.0 (not released yet, see >> https://github.com/ops4j/org.ops4j.pax.url/commits/url-3.0.x/) >> >> What held me in November 2023 (when I stopped working on Pax Web 10) was >> not the difficulty of OSGi CMPN implementation (it was roughly done), but >> the amount of itests in Pax Web 8/9 that didn't work in Pax Web 10 - but >> mostly related to things like CDI, JSF and Aries JAX-RS (based on CXF). >> The problem was the quality of jakarta.servlet based libraries which were >> not proper OSGi bundles (MyFaces, Prime Faces, Weld, Aries, ...) >> >> So now after I spent some time rebasing, I want to release Pax Web 10 soon™ >> without bothering too much on _all_ MyFaces/PrimeFaces/CDI tests. I'll keep >> you informed. >> >> kind regards >> Grzegorz Grzybek >> >> pt., 21 lut 2025 o 08:41 Jean-Baptiste Onofré <j...@nanthrax.net> napisał(a): >> >>> Hi folks, >>> >>> I would like to share the roadmap to Karaf 4.5.0. >>> >>> Karaf 4.5.0 will contain: >>> - a new "simple" features service (flat/simple resolver) >>> - new Karaf core services as alternatives to Pax * modules (replacing >>> Pax Logging by karaf-logging, replace Pax URL by karaf-url (with just >>> the JDK HTTP Client), ... >>> - more Karaf distributions, opinionated about the content: minimal (as >>> today but without Pax * cooupliing), simple (with the simple features >>> service, the alternatives to Pax *, ..), standard (the same as today >>> but with updated versions, we will discuss to "promote" simple as >>> standard for Karaf 4.6.x), integration (based on standard with Camel, >>> ActiveMQ, ...), cloud (based on simple with opentelemetry, k8s >>> support, ..., by default) >>> >>> As we did for Decanter, I will use Karaf 4.5.0 milestone to switch to >>> GitHub: >>> - GitHub Issues instead of Jira (the idea is not to migrate everything >>> from Jira to GH Issues, but to do it "manually" to do a meaningful >>> triage. >>> - GitHub Actions instead of Jenkins for CI/CD >>> It works well for Decanter (https://github.com/apache/karaf-decanter). >>> >>> Another work we should do is about the website. I think it would be >>> great to use Docusaurus to facilitate the updates and maintenance. >>> Website content should be updated too, including easily the >>> documentation on the website (thanks to md). >>> Any volunteers for that ? >>> >>> So, now about the ETA: >>> 1. Regarding "move to GitHub", if no objection, I will start the >>> effort today, creating .asf.yaml, GH workflows, creating GH Issues >>> with milestones >>> 2. Regarding the new "simple" features service, I already have >>> something. I think I can have a PR by end of next week. >>> 3. Regarding the new karaf services (alternatives to Pax *), I have >>> karaf-logging and karaf-url almost done (PRs will follow ~ 2 weeks). I >>> started karaf-web (powered by Tomcat, not depending on OSGi >>> HttpService, it's a pure Karaf Http service). I should be able to >>> share a draft PR. >>> Reasonably, we can plan Karaf 4.5.0 with all this in May. >>> >>> However, I have a question for the community: maybe, considering the >>> number of important changes, it makes sense to use Karaf 5.0.0 instead >>> of 4.5.0 ? Thoughts ? >>> >>> Thanks ! >>> Regards >>> JB >>>
