I see the need to deploy features with your own config.. or maybe even no config at all to install but not activate the decanter module.
If there is no other way I agree with this change.

It sounds a bit like a generic problem though. On one hand we have the requirement for a very nice experience when a user first installs decanter. So we provide the default configs. On the other hand for production you typically want a different config anyway so the default configs there rather hurt.

One generic solution might be to have a feature option config with default true. So the normal case would be unchanged and still Achim could use it like this:

<feature name="${project.artifactId}" version="${project.version}">
        <feature dependency="true">scr</feature>
<feature dependency="true" config="false">decanter-appender-elasticsearch-rest</feature> <feature dependency="true" config="false">decanter-collector-jmx</feature> <feature dependency="true" config="false">decanter-collector-process</feature>
<configfile finalname="/etc/org.apache.karaf.decanter.appender.elasticsearch.rest.cfg">mvn:de.nierbeck.karaf.decanter/Decanter-Module/${project.version}/cfg</configfile>


This is not a quick solution though as it requires a changes in karaf and a new karaf version. So lets have the core features for now but later eventually remove them again.


On 13.10.2016 08:28, Achim Nierbeck wrote:
Hi Christian,

yes it's actually more like double the features, as it's really hard to
seperate the config from the modules for re-usage.
A concrete example for this can be found here [1].

regards, Achim

[1] -

Christian Schneider

Open Source Architect

Reply via email to