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
