result: most prefer c) = a separate module - i'm fine with it. i propose "sling-org-apache-sling-models-caconfig" as name for the new git repository. i will take care of creating the repo.
> PS I think @Via is the way to go, not @Source, so a @ViaProvider. From there > you can adapt it to ValueMap or Resource or whatever you wish. this is a second step! - we can continue the discussion about the best approach for the API in SLING-7256 stefan >-----Original Message----- >From: Stefan Seifert [mailto:[email protected]] >Sent: Monday, January 7, 2019 1:33 PM >To: [email protected] >Subject: [DISCUSS] integration of sling models with context-aware >configuration - which way around > >there is a wish to integrate sling models with context-aware configuration >to add a new injector and injector annotation that allows to inject >context-aware configuration typed objects or property values in your sling >models. we have contributions for two approaches, one from the sling models >side [1] and one from the caconfig side [2][3]. > >i'm currently not sure what is the best approach. it is clear that we want >to avoid hard dependency of sling models to caconfig and vice versa. > >there are basically three options: > >a) add support for it in sling models API+impl with an optional dependency >to caconfig API (injector will not be available when caconfig bundles is >not there) >b) add support for it in caconfig API+impl with an optional dependency to >models API >c) create a separate module integrating both, as it is done e.g. for sling >models and sling validation [4], requiring to deploy an additional bundle > >I would prefer a) or c). > >WDYT? > >stefan > >[1] https://issues.apache.org/jira/browse/SLING-7256 >[2] https://github.com/apache/sling-org-apache-sling-caconfig-api/pull/1 >[3] https://github.com/apache/sling-org-apache-sling-caconfig-impl/pull/1 >[4] https://github.com/apache/sling-org-apache-sling-models-validation-impl > >
