JB, That's why I haven't had a chance to work with it yet since I'm working in Fuse exclusively and it is still on karaf 2.x. So there hasn't been a chance to work with karaf 4 yet other than very basic stuff of running it. But with the static profiles doing a proof of concept and self-contained prototype for demo and testing means that working with karaf 4 isn't out of line. It's one of the issues I have with Fuse is that I'm always a step behind the world. Although it does seem like Karaf 3 was sort of brief resting spot on the way to karaf 4 anyway.
So karaf-boot is leveraging the static profiles and using annotations to hook into that? I really think we may be in a back to the future situation with karaf. Ten years ago virtual machines as appliances were a new rage. Now they are rather common place. Docker is an extension and a slimming of that in a way. But karaf as appliances could really be an amazing market. With the amazing goodness of OSGi and the karaf shell and being able to SSH in to a container for management that's pretty interesting stuff. A whole different level of abstraction opens itself up. I think as much out of releasing the mind from concerns as anything. That's true when we started with OO and components and services and true at the appliance level as well. When you can look at an abstraction as a stand alone that can take care of its own needs you don't have to juggle it in your head. The other day I'd mentioned a gateway appliance I'd like. Feed it an appropriately decorated API interface and it creates server endpoints for incoming connections and makes client connections inward. But one could also have appliances for isolating databases behind web services. What the appliance makes possible is that physical and mental isolation where I just count on the service and don't have to think about how it co-exists in the same container with my other OSGi bundles. While we all work hard to make sure our exports and private packages are kept properly in their place in their bundles not every craftsman is equal in skill. And we all make mistakes. Karaf as an appliance mitigates that somewhat. If the young, bright developer I work with doesn't quite get the private package right and ends up with his bundle's contents exported to the world, well, if he's just exposing web services to isolate a database from the world then it isn't as serious a problem. Things like Drools rules engines with routes on JMS, SOAP, REST coming into it with a highly constrained set of rules for domain specific problem also become nifty little appliances. And so many of those have a nice fill in the logic feel to them. By that I mean that 90% of the Maven and profiles are the same. You just take the appliance outline and start working with the Camel, Java beans, and logic only. And testing! By God testing! Ahem. I don't know how many hours I've lost on CamelBlueprintTestSupport, PaxExam, and so on. If I can button up a nice appliance and simply run some JUnit tests with web services on a black box I'm a happy camper. One thing I've done in some of my tests environments that would work well with such black box appliances is put endpoint test simulator/stubs right in the bundles that are enabled/disabled by configuration flags. One project I'm on right now provides a set of services for the enterprise to get things like Invoices. Those REST and SOAP services use canonical models that have Dozer transforms to JDE models and a connection to JDE BSSVs (SOAP). During testing I set the flag and instead of using an OSGi service to talk directly to JDE it uses a different OSGi service that simply serves up dummy data from a map of XStream data models that I keep tucked away inside. But it let's me exercise all the routes, transforms, logic and deploy it early on for web tier folks to work against. With the static mechanics I can make an appliance of that and switch from test data to actual JDE with the flick of a configuration file setting. Or exercise it from my simple JUnit tests. And Jenkins should be simpler too. So yeah, this excites me a great deal. Brad On Wed, Apr 27, 2016 at 2:26 AM, Jean-Baptiste Onofré <[email protected]> wrote: > I don't think Karaf is a lot easier: it's a different approach, different > topology. It's not the same use case/packaging. > > It's exactly what karaf-boot is addressing: you use the annotations, we > deal with the packaging (you just define what you want). > > FYI, the static profile exists since 4.0.0 (it came with Karaf 4 and > profile introduction) ;) > > Regards > JB > > > On 04/27/2016 09:08 AM, Christian Schneider wrote: > >> I used the static profile here: >> https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-ds/app >> >> It allows to package a very slim karaf with your features. All bundles >> are directly referenced in the startup.properties. So there is no need >> for a feature service if your bundles are fixed. >> This makes karaf a lot easier to manage as you typically will not have >> refresh issues. >> >> The nice thing is that you can develop your application with normal >> features and decide about the packaging at a very late state. >> >> Christian >> >> On 26.04.2016 23:36, Brad Johnson wrote: >> >>> I looked at the profiles and static and find it interesting. I'll >>> have to work with it some. There's obviously a bit of a mind shift >>> there with the inheritance hierarchy. In my mind's eye I saw this as >>> something I'd run from a parent pom with a bunch of child bundle >>> projects but it would likely be better as an aside project separate >>> from the main build hierarchy itself. Which is fine. Decouples it as >>> a separate concern. Just a bit different than I'd imagined. >>> >>> I'll have to give it a swing. >>> >>> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
