[
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468685#comment-15468685
]
Stefan Seifert commented on SLING-6025:
---------------------------------------
bq. However I think we should move the heavy work to the build time and
process the annotations at build time and generate descriptor files (being it
XML or something else)
this would be easy to implement - but it would require all developers using
sling config to integrate a new maven plugin in their POMs only to generate
this metadata.
do we really want this? this is no longer lightweight to integrate. it could
also become complicated when version of annotations, config impl, maven plugin
are released and wrong versions are mixed together. we get the same complex
maintaining scenario as for scr plugin, scr annotations, scr generator etc.
wouldn't it be enough to do the classpath scanning lazily not before the
information it is really requested by any client, see also [this
comment|https://issues.apache.org/jira/browse/SLING-6025?focusedCommentId=15465187#comment-15465187].
this would mitigate concerns to slow down bundle deployments with unnecessary
classpath scanning.
btw. the classpath scanning would only take place A) when the specific bundle
header is present for the bundle and B) only for the packages this bundle
header defines.
> 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)
