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é <j...@nanthrax.net> 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 > <francois.pa...@openobject.fr> 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 <francois.pa...@openobject.fr> >>> 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é <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 >>>>>>
