Hi, Yes, I'm agree about the "polymorphic" approach, this is really a big advantage compare to others framework!
Users can using Karaf as dynamic runtime or with Winegrower for the static approach, according to their environment (on-premise, cloud....). We have all the features to make the new Karaf awesome :) François Papon [email protected] Le 13/02/2019 à 12:06, Jean-Baptiste Onofré a écrit : > Good point Serge. > > The huge advantage of Karaf is our "polymorphic" approach: we can > address lot of different packaging, use cases, etc. > > So, update is a key thing as well (more for dynamic approach than static > I think). > > I forgot to mention one area where we would need help: spread the word > and advertising. With the kloud initiative, I think we can seduce more > users, but they have to find Karaf and what they can do with it and how > Karaf can help them. > > I created new Jira yesterday evening, and now I'm starting from PoC that > you will be able to see as PRs soon. > > Thanks for your enthusiasm and your interest in Karaf ! > > Let's build the "new" Karaf ;) > > Regards > JB > > On 13/02/2019 08:29, Serge Huber wrote: >> +1 >> >> I really like this project, but I think we should also be careful to >> really leverage Karaf's strengths compared to other frameworks (such >> as Spring or others). >> >> I have a millions things that come to mind, how to address : >> - upgrades >> - rolling upgrades >> - leveraging Karaf to avoid building lots of containers and use >> instead OSGi to reduce the memory / CPU footprint >> - configuration of containers (passed as env or even centralized ?) >> >> There are also some very interesting developments coming to the JDK >> (in JDK 12) such as Project Loom that could help scale Karaf to >> millions of network connections on single instances without the need >> for NIO. >> >> We were talking in another thread about having a very thin OS-layer on >> top of Karaf to have baremetal performance and I think this could be >> very interesting in a cloud setup as well. >> >> Anyway, I'm just throwing ideas here, hope you don't mind :) >> >> cheers, >> Serge >> >> On Mon, Feb 11, 2019 at 2:11 PM David Daniel >> <[email protected]> wrote: >>> Thank you, >>> I would also be curious if it is possible to work to align some features >>> changes to be compatible with the osgi feature spec. >>> https://github.com/osgi/design/blob/master/rfps/rfp-0188-Features.pdf It >>> might be possible to bridge some of the gap between bnd and karaf. I love >>> things about both frameworks and would be super excited if they could work >>> together. >>> >>> David >>> >>> On Mon, Feb 11, 2019 at 7:01 AM Jean-Baptiste Onofré <[email protected]> >>> wrote: >>> >>>> 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é <[email protected]> >>>>> 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é >>>>>> [email protected] >>>>>> http://blog.nanthrax.net >>>>>> Talend - http://www.talend.com >>>>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> [email protected] >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>>
