adamcin commented on PR #31: URL: https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/31#issuecomment-1758743454
> 1. you propose to use this new features as lightweight alternative to the SCR metadata-based approach, making it easy to construct OSGI annotations filled with the configured data in the testing code. i'm worrying a bit about the approach to directly instantiate the OSGi component which effectively ignores all SCR annotations. this is fine for simple services as in your example, but if more stuff is used o.g. references to other services with complex reference mappings it will be left to the test developer to inject all of this properly, and it's easy to overlook something. still, if there is a need for such a simple approach and the test developer knows what he is doing, that's fine. a warning should be put for that in the documentation around the limitations of this approach. @stefanseifert I removed the javadoc text that you are referencing because of the confusion. The words "lightweight alternative" probably don't make any sense with how this feature has evolved. The initial and primary purpose for this extension is to support unit testing of service component constructors and activation methods with pure java types with the same granularity that other component methods can currently be tested. The secondary purposes that have evolved during development are to support verifying the expected mapping between config property names and annotation attributes, and to make it clearer when defining OSGi configurations for use in `registerInjectActivateService`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
