Absolutely, I fully agree ! I see the Karaf future as launcher (actually, it’s better than runtime) and adhoc features.
That’s the point of: - Karaf OSGi runtime is one subproject - Karaf Launcher as multiruntime launcher. And also agree to move forward fast ;) Thanks ! Regards JB > Le 9 nov. 2020 à 08:35, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > > To enhance what JB says there are other things to consider I think: > > 1. There is space for a "docker destructor" (everybody does a microservice > to read a config file these days, when the company hosting it in the cloud > checks the costs it realizes it can be reduced by at last 10 generally, > without perf or dev/responsabilities impact - what uservices are for). Here > the new subproject makes a lot of sense for me > 2. If you look the landscape today you have the choice between spring boot > or microprofile (or play but point is the same), ie a single company > project (yes MP is that as well since quarkus killed others in terms of > communication and even without respecting any of the spec it promotes, it > wins the $$ fight as expected, in particular since IBM and RH merged). > Indeed cloud makes vendor locking less important, but mainly for hosted > service, not for dev when the company have to maintain its project. OSGi > was an alternative until it goes to Eclipse (I agree it looks like a > cemetery) and moreover the overlayer OSGi specs adds to Jakarta/underlying > specs (often breaking part of them) + the build constraints it implies does > not help - here Winegrower helps a lot though without loosing OSGi libs. So > overall, if you are a company and want to bet on the future in terms of > stack you don't have the choice anymore. At Geronimo we proposed to "fork" > our Microprofile implementations to have a vendor neutral stack but seems > dev are far from stack decisions and therefore it will not help much. > > All that to say that 1 can be an interesting future for karaf and maybe in > some year become the TLP and Karaf the subproject. I also think it is the > moment to think about it to not wait for Karaf to have to go to attic. > Karaf is a launcher (main) + some tools (features mainly), it does not have > to leave that space, it will just leave the scope of this space IMHO. > > Hope it makes sense. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le lun. 9 nov. 2020 à 06:20, Jean-Baptiste Onofre <j...@nanthrax.net> a > écrit : > >> 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 >>>> >> >>
