Rest easy. Karaf is alive and well. In fact, the Pentaho DI (Kettle) product suite actually
converted to Karaf not that long ago. Previously it was entirely do-it-yourself code.
I really don't know of anything solid in the document area. I have OSGi and Equinox, but it's an antique book, has its own share of ra-ra stuff, and I don't know that Equinox would be of direct help. Although I believe that Equinox is the core of the Apache (formerly IBM) Eclipse
IDE product. Which is one of the oldest and most successful OSGi systems around.
Don't let the relative obscurity of OSGi deter you. Back in the middle 2000's, I worked with another Apache product series: the Avalon Inversion of Control container system. We had a lot of Java code that was basically batch processes and workflows, generally running on triggers or schedules, including quite a bit of ETL work. At the time, it was a decent option, since Pentaho didn't exist yet. But Avalon died and left no good heir. Spring came along a little later (they'd kicked me out the door by them). but Spring is rather low-level. Today I'd probably replace most of what we'd been doing then with either Pentaho or ServiceMix. And note that both of them are OSGi-based.
OSGi brings to service processes many of the same benefits that WAR and EAR modules bring to web processes. You get your own private classpath on a per-component basis so you don't have to worry about other components contaminating shared resources, but you also get cross-component communications. You can, indeed include a webapp servicing component. It's a lot better than splattering many stand-alone Java apps that aren't web-driven all over your servers. Instead, you collect them all up into modules and deploy them to the OSGi container in much the same way that you deploy webapps to a webapp container. You get a central control panel to manage them. And because they're a standardized architecture, it's easier to get people up to speed on creation and maintenance of OSGi apps. There are even
Maven archetypes for OSGi.