-
Notifications
You must be signed in to change notification settings - Fork 178
GH-1445 - Make DocumentationSource configurable #1446
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Introduces a generic StrategyLookup utility and makes DocumentationSource configurable via the spring.modulith.documentation-source property, following the same pattern as ApplicationModuleDetectionStrategy. Key changes: - Create generic StrategyLookup<T> utility in spring-modulith-core for reusable configuration-based strategy lookups - Refactor ApplicationModuleDetectionStrategyLookup to use the generic StrategyLookup utility, reducing code duplication - Add DocumentationSourceLookup with support for predefined strategies and custom implementations via property configuration - Add NoOpDocumentationSource as fallback implementation - Update Asciidoctor to use DocumentationSourceLookup instead of hardcoded static field - Make DocumentationSource interface public (was package-private) and add getDocumentation(JavaPackage) method for package-level docs - Add spring-configuration-metadata.json for IDE autocomplete support - Add comprehensive test coverage with DocumentationSourceLookupTests The implementation supports: - Predefined strategy: 'spring-modulith' (uses SpringModulithDocumentationSource) - Custom implementations via fully qualified class name - SpringFactoriesLoader fallback with deprecation warning (for compatibility) - IDE autocomplete via configuration metadata Signed-off-by: Yevhenii Semenov <zhe.semenov@gmail.com>
|
Can we change this to not affect |
|
Yes, we can, but that would result in essentially duplicating the ApplicationModuleDetectionStrategyLookup code in the docs module. Would this approach be acceptable? |
|
That's fine for now. I'd like to see how that looks before prematurely introducing an abstraction over an abstraction. |
Reverts the generic StrategyLookup<T> utility and restores the original ApplicationModuleDetectionStrategyLookup implementation in the core module. The DocumentationSourceLookup now contains an inline implementation of the lookup pattern, removing the dependency on the core module's generic utility. Key changes: - Restore ApplicationModuleDetectionStrategyLookup to original implementation with static initializer, Logger field, and switch statement - Delete generic StrategyLookup<T> utility class from core/config package - Duplicate lookup pattern inline in DocumentationSourceLookup with private helper method for SpringFactoriesLoader fallback This approach favors module independence over code reuse, keeping the core module unchanged while maintaining all documentation source functionality. All tests pass: 84 tests in core module, 15 tests in docs module. Signed-off-by: Yevhenii Semenov <zhe.semenov@gmail.com>
|
Done. The core module is now unaffected by changes. Please let me know if any other changes are needed. |
Introduces a generic StrategyLookup utility and makes DocumentationSource configurable via the spring.modulith.documentation-source property, following the same pattern as ApplicationModuleDetectionStrategy.
Key changes: