[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15397616#comment-15397616
]
Ian Boston commented on SLING-5886:
-----------------------------------
Has the content structure that drives this Configuration service been defined ?
Whatever the implementation of the Java API is, the content will be something
that needs to work with all implementations as it will, for many deployers of
Sling/AEM survive many upgrades to the Java code.
I am thinking of something like was expressed in the blog post referenced
ealier http://www.nateyolles.com/blog/2016/03/aem-slash-conf-and-confmgr but
written down as documentation. Without that there are no semantics. Perhaps
that already exists, I could not find it.
I guess it could be argued that the content structure is an implementation
detail, but so often it is an even more concrete API than the that the Java
API... unless configuration persisted in an opaque Blob form only edited with a
custom editor, and thats not use to anyone.
> 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)
