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