[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393970#comment-15393970
]
Alexander Saar commented on SLING-5886:
---------------------------------------
bq. what you describe is certainly correct for all system-level configuration
(esp. osgi configurations). for context-specific configuration it's often more
difficult because this configuration is directly related to the content, and
often it is managed on the production system itself by power-users or site
owners, and not by the devops team and their git repos. at least in our
experience and projects this is often the case.
[[email protected]] agreed and that's why I mentioned end-user specific
configurations before. but I don't really see a use case to overlay those
particular configs as osgi configs in a lower system. I would not really expect
that an end user configures or knows about specific settings that are
environment related. my intend here is to keep the first version as minimal as
possible.
> Sling Configuration - Initial Contribution
> ------------------------------------------
>
> Key: SLING-5886
> URL: https://issues.apache.org/jira/browse/SLING-5886
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Stefan Seifert
> Assignee: Stefan Seifert
>
> as discussed in the mailing list (see [my post from april
> 2016|http://apache-sling.73963.n3.nabble.com/RT-Use-cases-for-content-specific-configurations-in-Sling-amp-Contribution-td4060813.html])
> i want to contribute the wcm.io Configuration parts that are not
> AEM-specific.
> the current features of wcm.io Configuration are described here:
> http://wcm.io/config/
> the main goal is to support "context-specific" configuration, that means
> configuration that is different for different content paths (e.g. sites,
> tenants).
> during the contribution some changes and refactorings are required/planned,
> e.g.:
> * remove some dependencies to wcm.io build environment, Guava and others
> * remove the "application" distinction currently part of wcm.io Configuration
> in favor or a more path-based distinction
> * refactor the user-faced configuration API to further simplify it and
> support OSGi R6-style annotation classed for typed configuration access
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
