[ 
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473842#comment-15473842
 ] 

Stefan Seifert commented on SLING-6025:
---------------------------------------

i'll try an experiment with a bnd plugin. benefit is: it should work with both 
maven-bundle-plugin and bnd-maven-plugin.

where should we store the build-time generated metadata files to (default 
value, configurable)?
* OSGI-INF/xxx is not good, its sling-specific
* SLING-INF or SLING-INF/xxx ist not good because SLING-INF is often used as 
sling-initial-content, may conflict when the developers is not aware of it.
* SLING-CONTEXTAWARE-CONFIG-INF is quite long, but on the safe side...


> Context-Aware Config: Provide configuration parameter metadata
> --------------------------------------------------------------
>
>                 Key: SLING-6025
>                 URL: https://issues.apache.org/jira/browse/SLING-6025
>             Project: Sling
>          Issue Type: New Feature
>          Components: Extensions
>            Reporter: Stefan Seifert
>            Assignee: Stefan Seifert
>              Labels: contextaware-config
>             Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to