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