karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSS] Launching the kloud initiative
Date Mon, 11 Feb 2019 12:01:31 GMT
Thanks for your feedback David, nice idea about jlink, I have to
investigate a little about it, but definitely interesting.

Regards
JB

On 11/02/2019 12:52, David Daniel wrote:
> 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)
> https://openjdk.java.net/projects/portola/
> 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.
> 
> David
> 
> 
> On Mon, Feb 11, 2019 at 1:57 AM Jean-Baptiste Onofré <jb@nanthrax.net>
> wrote:
> 
>> 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
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message