+1 on promoting Karaf. May I remind you I produced a while ago a lot of resources comparing Karaf to other frameworks solutions?
https://docs.google.com/spreadsheets/d/1Js5qTXXugEOsp-5kUYoUbCKP1xt1dUx8efWZcGbm6C4/edit#gid=0 https://docs.google.com/document/d/1b1aJ_qimFxPxD9BDtaq21sW_h43kWUXrLVTWAFR_Coc/edit#heading=h.3uzgwjymutz https://docs.google.com/document/d/1cZp-KymYOVgpBiHVPdLAYfKY81U_LzfqVYCIcVd2Mfg/edit#heading=h.9xhre7dovs0q https://docs.google.com/document/d/1e4vvXhTNMaAbb7UgDSgmRjvVHp_nm981ztw33k0kHN8/edit#heading=h.2jt36cq65nll Of course, these resources can be improved, especially in light of the kloud initiative, but I think that it would help promote Karaf more aggressively. Regards, Serge... On Wed, Feb 13, 2019 at 9:06 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > 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 > > <david.daniel.1...@gmail.com> 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é <j...@nanthrax.net> > >> 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é <j...@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é > >>>>> jbono...@apache.org > >>>>> http://blog.nanthrax.net > >>>>> Talend - http://www.talend.com > >>>>> > >>>> > >>> > >>> -- > >>> Jean-Baptiste Onofré > >>> jbono...@apache.org > >>> http://blog.nanthrax.net > >>> Talend - http://www.talend.com > >>> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
