karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Discuss] Handling of initial bundles
Date Mon, 07 May 2012 09:38:43 GMT
I really like your setup it looks quite lean. It is very different from 
how karaf works though.
So I am not sure how easy it would be to karaf open enough to also 
support that style. Having boot time plugins could be interesting.
We already have the karaf activator that could be used for this. Perhaps 
that could be a basis for achieving such an open setup.

I have some questions about your setup:

- We use maven as a repository of binary artifacts (bundles, simple 
jars). What do you use for this purpose?
- While I see that your setup should work nicely it sure was a lot of 
effort to create. Why did you choose to do so instead of simply using 
plain karaf?
- What are the main features of karaf that make you use it compared to 
plain felix? The maven support can not be it :-)

Genrally I am not a big fan of completely open systems as they fragment 
the user deployments. If you mainly make your platform open then every 
user will use it differently.
That is not so good in relation to forming a community. So I am more a 
fan of choosing a good path and using it (a bit like gnome vs kde or mac 
vs linux). Of course in some areas modularity is really good but you 
have to be careful.


Am 07.05.2012 10:17, schrieb Jeremias Maerki:
> (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
> provisioning.)
> - "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
> directory.
> 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

Christian Schneider

Open Source Architect
Talend Application Integration Division http://www.talend.com

View raw message