On Wed, Jul 8, 2015 at 10:32 AM, Jean-Baptiste Onofré <[email protected]> wrote: > Hi Benson,
Hi Jean-Baptiste, thanks for giving my situation some thought! > > What you are doing looks like a container: why not using Karaf and features Well, I started out with plain Felix. We've ended up with Equinox. I'm assuming that Karaf needs Felix as opposed to Equinox, I'm sure you'll correct me if I'm wrong. Here's why we ended up on Equinox: We deliver a very large amount of read-only data to our users; it's statistical models and dictionaries. We don't want them to have to make copies. This data is mapped into memory, not just read from streams. I created a mechanism in which our bundles contain (via a fragment) this data as a compressed tar archive. The Activators call BundleContext.getDataFile(), and unpack the data into there. This works great in Felix, so long as only one process is using the container. However, a user with multiple processes needs multiple containers and multiple copies, because Felix disables getDataFile() entirely for shared containers. Equinox, on the other hand, allows for shared, read-only, data. I can load my bundles into a container, tell them to unpack their data, and then treat the resulting container as a read-only, shared, resource, complete with all the data. If we wanted to make use of Karaf, I'd have to give up on keeping the data seamlessly inside the container, or find out that I can, in fact, run Karaf atop of Equinox, or find out that Karaf has some other solution to the shared data problem. I confess that, until this email, I hadn't considered Karaf, so I didn't do any research on the question of Karaf's feelings about the framework implementation. > ? > > Karaf features are an interesting way to do provisioning, and with profiles > it allows you to do runtime provisioning and custom distribution > provisioning. > > For testing, allow me to disagree about pax-exam: it's not so complex, and > it runs fine by itself. I ran into a number of potholes, and some of my co-workers took one look at a typical configuration setup in a test class and needed a beer. An example pothole: the 'Parameterized test' feature appears / appeared to be completely broken. However, we're still using it. > > Regards > JB > > > On 07/08/2015 04:22 PM, Benson Margulies wrote: >> >> To expand on what I'm doing, in case of useful advice: >> >> Here I am, part of a team that builds and maintains a large body of >> Java code. Until recently, no OSGi at all. Maven is our build tool. >> IntelliJ is our predominant IDE. >> >> Recently, we decided to introduce OSGi into the picture. However, we >> can't just wipe out the past; we have many users who would have >> kittens if asked to use OSGi. And we would like to avoid radical >> changes in tooling. So we want to build bundles, and we want to test >> bundles, and we want to deliver a device that uses OSGi 'behind the >> application's back' for those who don't want to deal with it. That >> amounts to launching the framework via the API, and adding some >> packages to the system bundle to allow communication between 'inside' >> and 'outside'. >> >> We added Maven modules that use the bundle plugin to our major >> components. Where possible, we are using the existing OSGi status of >> common open source facilities (commons-io, Jackson, etc). We arranged >> things so that almost all communications are via services, not >> exported packages. Where there are exported packages, the bundles are >> simple in their structure (no packages exported from embedded jars), >> so that we could retain relatively plain processes for Java >> compilation. >> >> For testing, we pulled in pax-exam. I'm not especially thrilled with >> pax-exam; it seems complex and fragile to me. >> >> Now, I'm looking at provisioning; when the time comes to set up a >> container with the right set of components, how do we assemble all the >> dependencies without a bunch of manual metadata maintenance? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
