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
