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 >
