On 2016-08-01 13:29, Konrad Windszus wrote:
Can't we just use the resource merger approach for merging configs
(http://sling.staging.apache.org/documentation/bundles/resource-merger.html
<http://sling.staging.apache.org/documentation/bundles/resource-merger.html>)?
There probably needs to be a dedicated resource picker for
configurations, because neither the search path approach nor the
resource super type approach is applicable for configurations.
Sounds like a good match, I could imagine that way we could implement
merged configs fairly easily!
Clearly with devops automation you have some tooling already in place
which is using text files and does something to start AEM, so you can
add the stuff there - or - the configuration are content packages
after
all, so if the automation supports content packages in some form,
you're
done.
Agreed.
DevOps automation is nice, but for generating CRX packages with xml
config files it's not a great match:
* Puppet (not too sure about the others) is not exactly great at dealing
with xml files
* FileVault [1] is only available in Java, if you want to create proper
packages with it you have to call out to java from other languages
* Not having a standard approach makes every project implement their
homegrown solution (and waste budget where it could really be standard).
I've have seen a few awkward solutions for generating OSGi configs
* Alternatively (and this is what I've seen happening the most for OSGi
configs), people just accept the fact that they have to duplicate
configuration sets and then run into all the frustration Justin
described earlier
So I'm still in big favour of having a runtime solution.
Best Regards
Georg
[1]
http://jackrabbit.apache.org/filevault/
