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>
<bundle>mvn:${project.groupId}/Decanter-Module/${project.version}</bundle>
<configfile
finalname="/etc/org.apache.karaf.decanter.appender.elasticsearch.rest.cfg">mvn:de.nierbeck.karaf.decanter/Decanter-Module/${project.version}/cfg</configfile>
</feature>
WDYT?
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.
Christian
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] -
https://github.com/ANierbeck/Karaf-Decanter-Runtime/blob/master/Decanter-Feature/src/main/feature/feature.xml
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
