I don’t think there’s been much work on Karaf Boot lately. I hope they decide to pick that up again and just go with an opinionated way of doing Karaf Boot development as Spring Boot does. For example, use the PAX and Camel CDI as the mechanism of bootstrap and wire up and simply leave other mechanisms alone. If one wants to use blueprint or DS then go for it but Karaf Boot could just ignore it. That doesn’t deprecate those other technologies as far as Karaf is concerned, it just means that the subset or mindset of Karaf Boot would be CDI-centric.
Brad From: Serge Huber [mailto:[email protected]] Sent: Monday, April 10, 2017 4:13 AM To: [email protected] Subject: Re: Why is karaf so much easier to get working than older OSGi containers? I think that Karaf Boot is also important to get people started quickly. Or maybe even some kind of CLI interface and container integrations. I still find that building a new project with my own custom distribution is a big more work than I would like. Not to say that I don't love Karaf, I'm using it in more and more projects (4 professional and 2 personal !) cheers, Serge... Serge Huber CTO & Co-Founder T +41 22 361 3424 9 route des Jeunes | 1227 Acacias | Switzerland <http://www.jahia.com/> jahia.com SKYPE | <https://www.linkedin.com/in/sergehuber> LINKEDIN | <https://twitter.com/sergehuber> TWITTER | <http://www.jahia.com/vcard/HuberSerge.vcf> VCARD <http://www.jahia.com/> > JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a leading User Experience Platform (UXP) for Digital Transformation. On Sun, Apr 9, 2017 at 8:50 AM, Jean-Baptiste Onofré <[email protected] <mailto:[email protected]> > wrote: Hi Steinar, Great e-mail ! I think Karaf just works thanks to combination of what you said: features and resolver, prepackage features, convenient functionalities (shell, ACL, etc). I still think we should improve the dev experience providing samples in the distribution (as started). Regards JB On 04/09/2017 08:37 AM, Steinar Bang wrote: I first encountered OSGi in 2006. The place I worked at that time had (prior to my hiring) selected OSGi as the platform for server side components. The team I worked on extended this into the GUI space by creating an eclipse GEF-based IDE for data flows in the server system, where we integrated the server components into the eclipse instance for debugging. At that time it was a very promising technology, it was defined in a standard document that was actually readable, and it had (at that time, if memory serves me right) one complete free software implementation (eclipse equinox), two commercial implementations, and one free implementation (apache felix) just getting started. For my own part I was attracted to the lego building block possibilities of OSGi, and the fact that we were able to get the server components running inside eclipse and talking to eclipse GUI components by using OSGi services (even though what the server side components and eclipse used on top of OSGi services was very different). But... the problem with OSGi both then, and when I started looking at it back in 2013, was the practicalities in getting all bundle dependencies satisfied, and finding, and working around bundle version issues. In contrast to this, karaf has just worked for me (I took the plunge into learning karaf in the autumn of 2016). Or let me qualify that a little: since I started creating features for my own bundles, as a part of the maven build, karaf has just worked for me. So what I'm wondering, is: why is karaf so easy when everything before has been so hard? Is it because there is something magical in the feature resolution, compared to other way of starting OSGi runtimes? Or is it just that karaf comes prepackaged with features for the pax stuff (web, jdbc)? And that it is these prepackaged features that just works? Just some idle curiosity on a Sunday morning...:-) - Steinar -- Jean-Baptiste Onofré [email protected] <mailto:[email protected]> http://blog.nanthrax.net Talend - http://www.talend.com
