[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398126#comment-15398126
]
Stefan Seifert commented on SLING-5886:
---------------------------------------
[~ianeboston] definitely, such an configuration structure documentation this is
required, and ideally should be defined before it is implemented.
in my plan the storage structure of configuration is pluggable as well (as it
is in wcm.io today), but there should be a default configuration structure that
is active by default unless the deployer configures something different. this
structure should be something like
http://www.nateyolles.com/blog/2016/03/aem-slash-conf-and-confmgr
who can volunteer and contribute this documentation e.g. in the sling wiki to
be as close as possible to the existing implementation of
http://www.nateyolles.com/blog/2016/03/aem-slash-conf-and-confmgr to allow a
smooth transition?
---
for my side i have the next time slot for working on this and finishing the
first phase of contribution in mid-august. if anyone wants to work on it before
this feel free to fork https://github.com/stefanseifert/sling-config or commit
it to sling/contrib for further work.
this my rough plan for the next steps:
* apply the renaming depending on the current mail thread (last proposal was
"Context-aware configuration")
* further refine the SPI and implement the core configuration infrastructure
which provides the hooks for the SPI
* implement configuration metadata provider based on parsing the annotation
classes which are also used for the API
* implement at least one persistence provider based on
http://www.nateyolles.com/blog/2016/03/aem-slash-conf-and-confmgr
* implement parameter override providers like in wcm.io but in a separate
package to be deployed separately
* management API for the configuration editor
* implement as much of the "prio 1" usecases as possible and feasible from
https://wcm-io.atlassian.net/wiki/x/BQBLAQ - much of it is already covered in
wcm.io and i can reuse good parts of it, although refactoring is required
* have 80-90% unit test coverage, and some integration test coverage for the
parts difficult to test in unit test, and as API usage examples
* documentation
> 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)
