Karaf can work with Felix or Equinox: it's very flexible as you don't
care about the framework that you use.
To change from Felix to Equinox (or vice versa), you just have to change
in etc/config.properties:
karaf.framework=felix
to use felix
karaf.framework=equinox
to use equinox.
Regards
JB
On 07/08/2015 04:48 PM, Benson Margulies wrote:
On Wed, Jul 8, 2015 at 10:32 AM, Jean-Baptiste Onofré <j...@nanthrax.net> 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: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
