Hi Toni, That's an aspect of Karaf that we should improve, and that's exactly the purpose of:
1. The examples coming in the 4.2.1 (as part of the standard distribution): https://github.com/jbonofre/karaf/tree/DEV_GUIDE 2. karaf-boot. I started karaf-boot exactly to facilitate the view of Karaf for developers. Even if the focus is users first, we should extend to have a "Karaf developer friendly", even simplifying some OSGi parts for non OSGi people. It means that Karaf Boot will do choices: it will engage developers on some well defined patterns. Of course, there will be lot of different alternatives, but karaf-boot will follow one. The karaf-boot tagline is "just do your business code, karaf-boot deals with the rest". So basically, you will add some karaf-boot annotations in your code, and karaf-boot will create the artifacts, even the Karaf distribution, for you. However, I still think that our highest priority audience is users/devops, and the second audience is devs. François and I are working on Karaf Vineyard (API Registry/Gateway), focused really on service platform for users/devops. I would love to have some feedback and helps on karaf-boot (the repo is on my github). Thanks Toni ! Regards JB On 16/08/2018 12:14, Toni Menzel wrote: > Thanks everyone for your quick replies. > > I see your point, JB. "One of the key part of Karaf is use friendly." thats > what i mean by "opinionated felix distro". > It may sound as a bad thing but i mean it as a feature: it puts "batteries" > included onto the osgi fw, has opinions how to configure stuff and where > logs go and how to do things you normally would expect from a complete > solution. > I would expect use-friendliness should be a feature of every product. Who > wants software that is hostile at you ? ;) > > About "Product Project" well ok then. Thats the "Product Karaf" direction. > Good one! > > Though, there might be room for improvements in the area "Karaf for SDK > Vendors"? > Treat the following as insight into how we use Karaf "not" as a product but > as the fabric for (business-) developers. > Our customers are building developer experiences (e.g. APIs for specific > problem domains) on top of Karaf Minimal. > > 1. We take Karaf Minimal and create custom distributions with all > technical features embedded, preconfigured & tested.This often includes a > lot of messy "OSGi-fied" legacy projects too. > 2. We add business-centric/domain APIs to that distro. This is the > user-facing programming model. The only thing that leaks technically is the > fact that usually the model is being accessed as OSGi Services using DS. > But this is even exchangeable.We call the user-facing api "baseline api". > 3. They get all this as an "SDK" which is made of a Docker Image, > Zip-Assembly and as an on-demand/per-user cloud service (all runtimes) and > Baseline-APIs artifacts (compile target). > 4. They program against the baseline-api producing deliverables (usually > OSGi Bundles but could be anything accepted by the runtime). > 5. Delivery is very customer specific, ranging from pre-baking "all > included" docker images or an app-store-like SaaS Model. > > So we treat Karaf (and with it OSGi) as the internal fabric that is > technically exposed to the user (OSGi bundles, DS API, Diagnostics via > Karaf Shell etc.) but semantically not at all relevant (that is what the > baseline api is for). > > Its works very well but its nowhere as convenient as it could be. > Let me mention a few - knowing that we also work on some of them internally: > > - Limiting customisation to Maven is one thing (yeah.. everyone has its > build ecosystem) > - Karaf Boot seemed like a good start. But its went nowhere i think? [1] > - Customizers don't care about pre-attached (opinionated) spring or > enterprise repos that come (and change) with releases. > - Branding seems like a niche thing. Yes there are knobs everywhere > (webconsole, shell) but it could be addressed on a more systematic thing. > Do other people care? > > Maybe this helps seeing Karaf not only as a product. > > > [1] https://github.com/apache/karaf-boot > > > > *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com > <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>* > > On Thu, Aug 16, 2018 at 10:48 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> Hi Toni, >> >> I know a fairly large set of users that use Karaf without knowing OSGi. >> >> That's why it's a polymorphic container: some use spring, some use OSGi, >> some use blueprint, some use directly war, etc. There are several facet >> of using Karaf. >> >> About the distribution, to be honest, I only know users of standard >> distribution: either directly Karaf vanilla and then installing features >> and their applications, or creating their own custom distribution >> starting from the standard one. They don't necessary use the enterprise >> features, it's more the standard distribution + their own features. >> >> One of the key part of Karaf is use friendly. That's the difference >> starting from the framework. When you start from felix framework, it's >> up to you to construct all: logging management, hot deployment, ... >> Starting from Karaf it's a turnkey solution, having all user facing >> aspects. >> Karaf container and all its subprojects are really focused on user. >> >> Look at Decanter: it's tremendous simple solution but it does the job >> and users just use it. >> >> Karaf is a "product project", it's not a SDK. It's a multi-purpose >> runtime, powered by OSGi, but OSGi is not necessary the user facing model. >> >> That's why, as a "product project", I think it makes sense to have >> regular release pace. >> >> Regards >> JB >> >> On 16/08/2018 10:09, Toni Menzel 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>* >>> >> >> -- >> 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
