Karaf is used / consumed heavily in the SDN world (see OpenDaylight & its ecosystem).
For that community they do treat Karaf as a SDK for developing their apps, its also of course their runtime. The long support runs we provide for Karaf major versions is seen as a benefit as SDN deployments typically run major infrastructure. The release pace is a function of available time from the community - speaking from my experiences with Karaf releases they are a fare amount of work; more hands involved in testing, stabilizing builds, etc are always welcomed :) As to how Karaf is presented; Karaf is many things to many people, I'd rather keep the open development possibilities than restrict them. On Thu, Aug 16, 2018 at 5:40 AM Toni Menzel <toni.men...@rebaze.com> wrote: > > As mentioned, here are some more thoughts on Karaf audience/usage. > > Do you know how Karaf users consume/use Karaf? This is important to get a > good release cycle and granularity. (as teased by JB on this list recently). > > Why i am mentioning that? Well,i always felt that Karaf (the container) is > a rather large thing with all its feature repos coming with it. I think > thats why Karaf releases where coming rather slow in the past. (correct or > not?) > > *1. Karaf as an opinionated felix distro* > > This "batteries" included feature is (was?) a core selling point of Karaf > but is this really how people use it? > I know at least two larger customers who are baking their own Karaf > distribution anyway based on the minimal profile. > > So i am asking, wouldn't it make sense to release the "base" runtime (say > Felix+Karaf infrastructure like pax-url, feature system, configuration > system) independently? Similar to what you get with Karaf minimal. > > Depending on how Karaf is used in the real world (do you know?), here are > some radical thoughts on my/our personal usage: > > - Karaf Minimal becomes "Karaf Runtime" because its base unit you can > put everything on top (even at runtime). > - Karaf Standard/Enterprise becomes the "Karaf SDK" since has the > kitchen-sink nature that is great when you want to tinker with > Spring,Hibernate etc. > > Also, wouldn't it make sense to release the maven-plugin independently? > > Those changes might seem of no importance to Karaf insiders (because you > get all of that already when building your own distro) but at least I only > found Karaf reasonable for a lot of usecases until i found out how to > really only get the "runtime" part. Now i can say that for me Karaf is an > opinionated felix distro (yes.. not only that but you get the point). > > *2. Karaf as polymorphic container* > > On the website Karaf is marketed as "Karaf can host any kind of > applications: OSGi, Spring, WAR, and much more". Is that how people really > use it? I mean.. are Spring (Boot..) people happy living inside Karaf? > Every OSGi-savvy person recommends going DS, staying with OSGi spec > standards and avoid War. - pun intended. > Yeah, its great for demos but is it worth the effort? - also to keep this > "working". And - from experience - i can tell that its also not a > recommendable migration path. It sounds great but Hibernate and friends are > actually quite hostile to your OSGi framework instance introducing a lot > more complexity into your system. And if even OSGi-savvy people have > problems troubleshooting such cases, how should a team of beginners do that? > > *3. Karaf as a better solution for Microservices* > > Guess i save this for another post, too easy to turn this into a rant. Let > me just say: i think Karaf is one of the few answers to the pervasive > Microservice/Spring Boot ecosystem. But it is not obvious and people stay > away from it because. Again, this COULD go very long, but it is not the > right place. > > Any thoughts? > > * What is Developer Ergonomics <https://medium.com/rebaze>**? * > > > > *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com > <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
