Support for application-module-specific Liquibase migrations

Liquibase users need the same module-aware migration behavior that Flyway got in #1067:
• Discover ApplicationModules and their dependency graph.
• Execute module-scoped Liquibase changelogs in topological order (respecting module dependencies).
• Allow subset execution in @ApplicationModuleTest (only the tested module + its upstream dependencies).
• Keep a small/global changelog optional (extensions, baseline).

Why
Large moduliths commonly use Liquibase for enterprise features (rollback, labels/contexts, advanced tracking). Aligning with #1067 enables consistent behavior across tools and simplifies testing & CI.

Proposed approach (high level)
• New Boot auto-configuration (opt-in via spring.modulith.runtime.liquibase-enabled=true).
• At runtime, create one SpringLiquibase bean per module (plus optional _global) and set:
• changeLog: classpath:db/changelog//db.changelog-master.yaml
• labels: module: (optional)
• defaultSchema: configurable per module (optional)
• Determine topological order via Modulith’s module graph and register beans accordingly.
• Selective execution in tests via property (e.g. spring.liquibase.modules=customer,order) so only the tested module (+ deps) run.
• Keep single-bean alternative (master changelog + label filtering) for teams preferring that style.

Configuration (example)

spring.modulith.runtime.liquibase-enabled=true
spring.liquibase.modules= # e.g. "customer,order" (tests)
spring.modulith.runtime.liquibase.default-schema.<module>= # optional per module
spring.modulith.runtime.liquibase.global-changelog=classpath:db/changelog/_global/db.changelog-master.yaml

Acceptance criteria
• With …liquibase-enabled=true, Modulith executes module changelogs in dependency order.
• @ApplicationModuleTest can restrict execution to the module under test (+ its upstream deps).
• Works with both SQL and YAML changelogs; supports Liquibase labels/contexts.
• Sample app + tests included (integration tests verifying order & subset).
• Documentation shows folder layout, properties, and test patterns.

Open questions
• Should the subset expansion (module + deps) be automatic in @ApplicationModuleTest via a ContextCustomizer?
• Default behavior for missing module changelogs (skip vs. fail fast)?
• Interaction with multi-schema setups (defaultSchema per module).

Sketch (pseudo-code)

@Configuration
@ConditionalOnProperty(name="spring.modulith.runtime.liquibase-enabled", havingValue="true")
class ModuleAwareLiquibaseAutoConfiguration implements ApplicationContextAware, BeanDefinitionRegistryPostProcessor {


  @Override
  public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
    var modules = ApplicationModules.of(applicationContext);
    var topo = modules.getModuleGraph().topologicalSort();

    // Optional: global changelog first
    registerLiquibase(registry, "liquibase-global", globalChangeLog, ds, null, null);

    for (var m : topo) {
      var moduleName = m.getName();
      var changelog = "classpath:db/changelog/" + moduleName + "/db.changelog-master.yaml";
      var labels = "module:" + moduleName;
      var schema = env.getProperty("spring.modulith.runtime.liquibase.default-schema." + moduleName);
      var shouldRun = shouldRunFor(moduleName, env.getProperty("spring.liquibase.modules")); // subset in tests
      registerLiquibase(registry, "liquibase-" + moduleName, changelog, ds, labels, schema, shouldRun);
    }
  }
}

Related
• #1067 (Flyway)
• #1066 (module identifiers in dependency order)

Start by reading the Flyway work in #1067, then inspect the ApplicationModules dependency graph and @ApplicationModuleTest integration points mentioned here. Done means an opt-in Liquibase configuration supports module changelogs in dependency order, test subset execution, SQL and YAML changelogs, and the sample integration tests and documentation described in the acceptance criteria.