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.
Christian
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.
HTH
Jeremias Maerki
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
