One nice thing about the feature files we currently use is that they
are globally adressable using a maven coordinate. So by support reading
features we could create a very small distro that can read all it needs
from maven repos. If maven access is not allowed/possible in an
environment we can nicely use our system dir to make karaf fully self
contained.
So feature reading would allow us to have a fixed small binary distro
that can easily be customized by users. They can already change the
feature set they want and with startup feature loading they could also
customize the startup feature without build their own distro. We could
extend that to some commands that allow reading features into the system
dir. So the user could download a small karaf binary, execute some
commands at a place with maven repo access and as a result get a
customized distro he can then use in a closed company environment. This
would be much simpler then building your own distro with maven like you
have to do it now.
Honestly the above thing would also work nicely without loading startup
bundles from a feature file. I doubt anyway that people really need to
change the framework bundles.
Supporting the subsystem spec sounds great to me. So that may be a good
reason to delay supporting feature reading and then only support it for
the subsystem spec features. Any way the startup feature loading from
xml is not that big of an issue for me. I thought it is a nice feature
but it is not really crucial.
Now to the last part about maven support in karaf. I think at the moment
maven support is a key feature in karaf that makes it much easier to use
than other frameworks. It allows to install big frameworks like camel
and cxf with just some simple commands. Whenever I show this to people
who do not know karaf they are really impressed by it. So while I am
sure that maven is not ideal for OSGi bundles it is the best we
currently have.
I fully support replacing maven with something better like obr but only
when it is ready. So the key to that would be that all relevant bundles
are available in OBRs. We then also would need a url for adressing
bundles from OBRs (not sure if we have such a thing already). So
replacing maven sounds like a good goal for the future but not near
term. Perhaps in the end maven and OBR grow together anyway and the big
maven repos simply additionally support OBR. So you would address the
entry points into the OBR as maven coordinates and resolve dependencies
using the OBR features.
Christian
P.S. Thanks for your nice words about my contributions to karaf. I
really like Karaf and see a great future for it. So I guess I just have
to learn to step on less toes on the way :-)
Am 02.06.2012 19:26, schrieb David Jencks:
Hi Christian,
I'm not a big fan of xml when dealing with not-very-complicated data. The data
in startup.properties is just about the right complexity for a properties file.
A feature repo is too much: it can contain more than one feature, and the name
of the startup feature has to be hard coded.
Furthermore, now that the subsystem spec is fairly final I think we should look
towards using spec features as much as possible and start thinking of karaf
features as possibly obsolete. Pushing the karaf feature xml format into the
framework startup is exactly opposite of this goal.
I looked back and reviewed your patch. Mostly I'm impressed with how much
you've contributed in the last few months :-) I wish I had as much time to
spend on karaf.... Your patch is indeed pretty simple and small but my
objections are really to the idea of using xml during startup rather than the
implementation. I might have missed it but didn't think you addressed the
question of why xml was better than a properties file.
My views might not be shared by many others, for instance I really think we
should try hard to make karaf runtime independent of maven including the mvn
url handler, and I'm not sure anyone else agrees with me.
thanks
david jencks
On Jun 2, 2012, at 2:17 AM, Christian Schneider wrote:
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
