karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Daniel <david.daniel.1...@gmail.com>
Subject Re: [DISCUSS] Launching the kloud initiative
Date Mon, 11 Feb 2019 11:52:17 GMT
I really like the idea of the static build and features in code.  I think
the jdk is making great strides in getting java running well on docker
java 9 jlink for small images that can be copied and spun up quickly
java 10 defaults improvements https://aboullaite.me/docker-java-10/
portola for running java on musl (alpine without glibc)
loom is coming for not spinning off a ton of threads
If at all possible I would love to be able to build a minimal karaf
distribution with jlink from java module files that were generated from the
karaf resolver.  I think this might be a little much though and don't even
know if it is possible.  Just something that might be able to be looked at
while the code is being written.


On Mon, Feb 11, 2019 at 1:57 AM Jean-Baptiste Onofré <jb@nanthrax.net>

> Hi guys,
> As we now have released Karaf runtime 4.2.3 and started 4.3.x, I think
> it's time to discuss and move forward "concretely" about the "kloud"
> (Karaf for the Cloud) initiative.
> I think the first approach is focused on the developers and devops. I
> created the following Jira:
> https://issues.apache.org/jira/browse/KARAF-5923
> https://issues.apache.org/jira/browse/KARAF-6148
> https://issues.apache.org/jira/browse/KARAF-6149
> https://issues.apache.org/jira/browse/KARAF-6150
> The idea is really to simplify the features generation and distribution
> packaging.
> For the features generation, I'm thinking on annotations directly in the
> code (in package-info.java for instance) describing the features needed
> by the application. The annotations scanner could then create the
> features XML using the code itself and the annotations. That would allow
> us to not relay on Maven and be able to support CLI/Gradle/Maven. In the
> case where the user uses Maven, we could better leverage Maven to get
> some details. The idea is to especially easily create features XML to
> build "static" runtime (that make sense for the cloud).
> After the features XML generation, we should have a easier way to build
> a distribution. We also have to provide multiple "packaging output" like
> archives (zip/tar.gz), uber jar (embedding karaf and user application),
> docker image, openimage, kubernetes meta, ...
> The idea is to have a ready to go packaging for the cloud.
> For the cloud perspective, the distribution should be
> "immutable/static". Currently, the resolver we have is great for
> "dynamic" deployment but could be painful for static one (dealing with
> refresh, multiple versions resolution, etc).
> I'm proposing to create kind of "static" resolver
> (https://issues.apache.org/jira/browse/KARAF-6147) directly taking boot
> features and installing straight forward what's defined in the features.
> It should result with a more "predictable" behavior, really helpful from
> a cloud perspective.
> Finally, I created some Jira about general improvements for the cloud
> and docker:
> https://issues.apache.org/jira/browse/KARAF-6111
> https://issues.apache.org/jira/browse/KARAF-4609
> I think you got the overall idea: dramatically simplify creation of
> distribution packaging karaf with user application (for developer),
> simplify the packaging outputs and bootstrapping on cloud (for devops).
> If you think it could be helpful to have a doc on confluence about that,
> please let me know I will create it.
> We all know that Karaf is an amazing runtime. To convince more and more
> users and give a new dimension to Karaf, I really think that the "kloud
> initiative" is a must have. We will have a runtime that can address both
> static and dynamic bootstrapping approach, one runtime for multiple
> services or one runtime per service, etc.
> Thoughts ?
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message