I added an issue for creating a customized standalone karaf from a
standard karaf distro: https://issues.apache.org/jira/browse/KARAF-1519
It would be great if you could review and add your requirements.
Christian
Am 03.06.2012 17:28, schrieb Dan Tran:
On Sun, Jun 3, 2012 at 5:19 AM, Christian Schneider
<[email protected]> wrote:
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.
From the perspective of karaf's feature, this is a big plus for us
since we deliver karaf to our client
in a isolated environment.
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
