Hallo, want to contribute to the discussion as well. We recently migrated a very large codebase from JbossOSGi to Karaf. The main reason was that we already had invested a lot into OSGi and that with Karaf you can more selectively expand platform functions.
For the future of Karaf this means: it should still be open to different framework and libraries, it can still benefit from OSGi. Some newer frameworks like CDI and Micro Profile should be present. It’s unlikely that spring boot or quarks users would switch, but if you can use spring or cdi then there is a change some people would consider Karaf. The biggest stream of users is expected to come from the JavaEE camp, if they can keep using those APIs and also get many of the JakartaEE implementations Karaf would be a good runtime for at least those... Having said that, working on the footprint of Karaf is certainly a good goal, as well as support for deploying a collection of libraries without the need to wrap all in bundles would be starter friendly (but in the end it’s a non issue for us). Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Jean-Baptiste Onofre <j...@nanthrax.net> Gesendet: Monday, November 9, 2020 6:20:26 AM An: dev@karaf.apache.org <dev@karaf.apache.org> Betreff: Re: Thinking about Karaf 5 modulith runtime Hi Lukasz, And thanks for your feedback. I think it’s a fair feedback about the current situation. I think Karaf is one thing and OSGi is another one (for a project perspective). So, we can drive Karaf roadmap to something different if it makes sense. Remember, first ServiceMix version was Spring focus before moving to OSGi. So the other way around can be true. We can use OSGi internally, and provide some user facing different approaches. Karaf devx/tool is the first thing to achieve: improve developer experience, simplify test and runtime assembly. I agree that we don’t have the marketing power of Pivotal (we are "real" open source project after all ;)) and we don’t have a single company providing marketing power. I think we have two personas: 1. People already using Karaf, and for them, we have to improve and provide a better runtime generally speaking for sure 2. People not using Karaf, using spring boot, cdi, whatever. I doubt we will convince them to switch to Karaf with another programming framework. The purpose is more to try to attract them with a runtime directly supporting their applications but providing adhoc features out of the box for them (the purpose of a runtime). That’s what I have in mind for now: improve (thanks for devx and other new features), and attract. Regards JB > Le 9 nov. 2020 à 02:42, Łukasz Dywicki <l...@code-house.org> a écrit : > > I am quite late for this discussion and haven't watched your ApacheCon > talk, hence pardon my points if they're wrong. > > Reorganizing code base is highly appreciated since karaf source tree > grew since 2.x without any major changes in directory structure. > Till these days it is confusing to me where "enterprise" features come > from (in terms of maven POM) and where "framework-static" lives. > I do believe that improving tooling and docs will help a lot. I keep > getting into troubles with tooling every-so-often. > > > The question where Karaf should or could go.. that's quite difficult to > answer. From what I see OSGi marketplace is shrinking year-to-year and > recent move/merger of OSGi Alliance with Eclipse Foundation is, in my > personal opinion, result of deep organization failure. It simply did not > attract enough of people to use, promote and pay for their certification. > Beside Eclipse IDE there are still many products which are based on OSGi > itself. Yet thanks to above move OSGi and Eclipse are closer than > before making all black PR of Eclipse IDE directly transferable to > entire OSGi ecosystem. > > In curium stances we have we need to be rationale about whether we can > or can not fight for "microservices" term any more and if any major > changes will move us ahead. > I doubt if positioning Apache Karaf as an alternative to Spring Boot or > other tools in this category will help. I think they fight for slightly > different projects than we ever did. Karaf always been middleware > platform and not application framework. Making apps on top of it is > doable, but probably done mainly by people who used runtime already and > didn't want to complicate deployment. We're pretty far from being first > choice for application runtime as there are quite many alternatives. > Most of applications will not even feel benefit of OSGi. > We simply have no marketing power to fight over media buzz sustained by > other (especially Spring) communities. Most importantly we have no man > power to keep up all satellite projects around. The nature of > Spring/Pivotal development is based on number of paid developers and > consultants who actively contribute to development of their ecosystem > components. Above all they keep doing technical sales promising fast > delivery of projects in numbers which we probably never heard of. > I know that comparing number of stars on github is worst metric to be > used, yet we have 505 starts whereas boot have 51k. *90 times more*. > > I am afraid we have none of above prerequisities (manpower, marketing, > money). All efforts which we depend upon are distributed around multiple > top level Apache projects (CXF, Camel, AMQ) and surroundings such as OPS4J. > We can't get everyone around working on Karaf/OSGi integration, simply > because focus of other communities is somewhere else. This means we will > have to ship these components and later maintain integration. Shutdown > of Apache Geronimo shows that application server era is over and what I > hear between sentences is re-birth of OSGi enabled application platform > which Apache Geronimo once promised to become. > Again, I don't think that switching to microprofile will help us much > cause there are existing projects such as Apache TomEE who do that > already with help of CDI. What is our advantage over their? OSGi which > failed to attract people over past decade? Or smaller footprint in era > of GraalVM? > > Please hear me out. I am not saying that easing adoption of OSGi and > Karaf is wrong. I am just saying that its gonna be very difficult to > promote it and get other people engaged. So better focus on community we > have, serve their needs and simplify their life. If we solve their > trouble and do it in reliable way we have chance to survive. Maybe > adoptions will continue to grow and will bring more people to help > moving forward. > > Kind regards, > Łukasz > -- > Code-House > http://code-house.org > > > On 04.11.2020 05:59, Jean-Baptiste Onofre wrote: >> Hi guys, >> >> François and I started to think about Karaf 5 and give an even modern flavor >> to Karaf, including potentially lot of refactoring and changes. We think >> it’s a must have in our patch to the "main modulith runtime". >> >> Before sharing all details (some have been shared during my talk at >> ApacheCon), we want to move forward on a PoC branch. >> >> However, we would love to have your inputs and thoughts (think wide ;)). >> >> So, please, if you have ideas, comments, criticism ;), send me an email and >> I will reply and eventually include your points in the PoC. >> >> Thanks ! >> Regards >> JB >>
