Parent: #123
Is your feature request related to a problem? Please describe.
The current Spring Boot plugin starter modules contain repeated auto-configuration code across raw-data, JDBC, AI, tracing, and store integrations. Most modules repeat the same structure: AutoConfiguration.imports, @AutoConfiguration, @ConditionalOnClass, @ConditionalOnProperty(enabled=true), @EnableConfigurationProperties, and @ConditionalOnMissingBean.
This makes the starter layer harder to maintain as part of the Spring Boot 4.1.0 / Spring AI 2.0.0 upgrade in #123. It also blurs module responsibilities in some places: starter artifacts sometimes contain meaningful implementation code instead of acting as thin dependency entry points.
Describe the solution you'd like
Introduce a shared Spring Boot autoconfigure module and turn plugin starter artifacts into thin dependency aggregators.
Proposed module shape:
- Add
memind-spring-boot-autoconfigure.
- Move Spring Boot auto-configuration classes,
@ConfigurationProperties, conditions, configuration metadata, and shared auto-configuration test support into that module.
- Keep implementation modules separate, such as JDBC plugins, raw-data plugins, Spring AI plugin, tracing plugin, and store implementations.
- Keep individual starter artifacts, but make them mostly POM-only dependency aggregators.
- Optionally add a top-level
memind-spring-boot-starter for the common all-in-one embedded runtime setup.
Target structure:
memind-spring-boot-autoconfigure
- JdbcPluginAutoConfiguration
- RawDataDocumentAutoConfiguration
- RawDataImageAutoConfiguration
- RawDataAudioAutoConfiguration
- RawDataAgentAutoConfiguration
- RawDataToolCallAutoConfiguration
- RawDataJacksonAutoConfiguration
- MemindAiAutoConfiguration
- TracingAutoConfiguration
- Store auto-configurations
memind-plugin-xxx-starter
- depends on memind-spring-boot-autoconfigure
- depends on the relevant implementation module(s)
This should preserve opt-in dependency granularity while removing most duplicated Java auto-configuration code.
Describe alternatives you've considered
- Keep the current per-plugin starter Java code. This avoids a migration now, but the repeated starter pattern will continue to grow and makes future Spring Boot/Spring AI upgrades more expensive.
- Merge all plugin starters into one large starter. This reduces module count, but it would force users to pull unrelated dependencies such as Tika, Spring AI provider libraries, database drivers, and tracing dependencies.
- Extract only a small internal helper module. This reduces some duplication, but still leaves auto-configuration metadata, imports, and tests scattered across many modules.
Additional context
Acceptance criteria:
- A new shared autoconfigure module owns Spring Boot auto-configuration classes and configuration properties.
- Existing plugin starter artifacts remain available for user-facing dependency selection.
- Individual starters are reduced to thin dependency aggregators where practical.
- Auto-configuration still backs off correctly when required classes, beans, or properties are missing.
- Existing property prefixes remain compatible unless a breaking change is explicitly documented.
- Configuration metadata is generated for all
@ConfigurationProperties.
- Tests cover:
- no required dependency/class present,
- no required bean present,
- user-provided bean override,
- enabled/disabled property behavior,
- starter composition with representative dependencies.
memind-plugin-mybatis-plus-starter is evaluated for splitting implementation code from starter auto-configuration.
- The README/README_zh dependency guidance is updated to match the new starter/autoconfigure structure.
Relevant files/modules:
memind-plugins/memind-plugin-spring-boot-starters/
memind-plugins/memind-plugin-ai-spring-ai/
memind-plugins/memind-plugin-jdbc/
memind-plugins/memind-plugin-rawdatas/
memind-plugins/memind-plugin-tracing-opentelemetry/
memind-dependencies/pom.xml
README.md
README_zh.md
Parent: #123
Is your feature request related to a problem? Please describe.
The current Spring Boot plugin starter modules contain repeated auto-configuration code across raw-data, JDBC, AI, tracing, and store integrations. Most modules repeat the same structure:
AutoConfiguration.imports,@AutoConfiguration,@ConditionalOnClass,@ConditionalOnProperty(enabled=true),@EnableConfigurationProperties, and@ConditionalOnMissingBean.This makes the starter layer harder to maintain as part of the Spring Boot 4.1.0 / Spring AI 2.0.0 upgrade in #123. It also blurs module responsibilities in some places: starter artifacts sometimes contain meaningful implementation code instead of acting as thin dependency entry points.
Describe the solution you'd like
Introduce a shared Spring Boot autoconfigure module and turn plugin starter artifacts into thin dependency aggregators.
Proposed module shape:
memind-spring-boot-autoconfigure.@ConfigurationProperties, conditions, configuration metadata, and shared auto-configuration test support into that module.memind-spring-boot-starterfor the common all-in-one embedded runtime setup.Target structure:
This should preserve opt-in dependency granularity while removing most duplicated Java auto-configuration code.
Describe alternatives you've considered
Additional context
Acceptance criteria:
@ConfigurationProperties.memind-plugin-mybatis-plus-starteris evaluated for splitting implementation code from starter auto-configuration.Relevant files/modules:
memind-plugins/memind-plugin-spring-boot-starters/memind-plugins/memind-plugin-ai-spring-ai/memind-plugins/memind-plugin-jdbc/memind-plugins/memind-plugin-rawdatas/memind-plugins/memind-plugin-tracing-opentelemetry/memind-dependencies/pom.xmlREADME.mdREADME_zh.md