karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: [Discuss] Handling of initial bundles
Date Mon, 07 May 2012 08:17:10 GMT
(hooking into a random point in this thread, mostly agreeing with
Guillaume and David)

I'd like to offer my view on the topic. I've recently started moving
away from the Karaf bootstrapper (still using many Karaf bundles,
though). I ended up writing my own bootstrapper because I thought the
current one does too much and imposes certain decisions.

Here's where I am now:
- "lib" directory for the bootstrapper (18KB) + framework(s) and service
adapters (Commons Deamon, Wrapper etc., in the future to be implemented
as plug-ins using META-INF/services like with the framework).
- "lib/endorsed" directory: not nice but unfortunately I can't seem to
do without, yet.
- "bundles" directory for startup bundles. Can optionally have
subdirectories with the start-level as name, ex. "bundles/10" for
start-level 10. (No startup.properties) (Even this could be a "bootstrap"
plug-in so others can implement their own choice of initial bundle
- "etc" directory: minimally only contains a system.properties,
framework.properties and jre.properties.

In the production deployment, the installation really just contains a
minimal set of 3 bundles (compendium, my initial provisioning
implementation bundle and config admin). Initial provisioning fetches
the management agent from a central place and invokes that to actually
deploy the application.

That allows me to put minimal configuration on each server and reduce
the frequency in which the bootstrapper has to be upgraded. All the rest
is fetched from a central deployment server.

In my development environment, fileinstall and many other bundles are
put in the "bundles" directory so I get a "Karaf-like" setup, skipping
the actual deployment server (actually the local instance serves as that).

I don't work with Maven, so I don't personally like that dependency,
even it's just the directory layout in the "system" directory. The
startup.properties doesn't even need to be kept in sync with that

Since I'm seeing multiple desires in this thread, why not make the
container/bootstrapper much more modular and give the power to the users
to choose their favorite setup? Karaf already offers a ton of very
useful bundles that can but don't need to be used. You could extend that
approach to the bootstrapper.

Just my 0.05 CHF.

Jeremias Maerki

View raw message