Comment From: wilkinsona

Why? What do you want to be able to customise that cannot already be customized with a liquibase.integration.spring.Customizer<Liquibase> bean? We won't increase the public API without a reason.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: shitikanth

One valid reason would be provide a custom resourceAccessor implementation - it is a final field in Liquibase so can't be customized using Customizer<Liquibase>.

Liquibase's spring integration has a bug when used with cloud native images (e.g. created with mvn spring-boot:image) where it resolves resources included by includeAll to a different path when run with an image as opposed to when you run locally or through a jar. For example:

databaseChangeLog:
  - includeAll:
      path: classpath:/db/changelog/2025/09/

with a changelog at classpath:/db/changelog/2025/09/0001-changelog.yaml would resolve to path db/changelog/2025/09/0001-changelog.yaml when run using a jar and BOOT-INF/classes/db/changelog/2025/09/0001-changelog.yaml when run using the cloud-native image.

Ability to customize the resourceLoader or resourceAccessor would provide an elegant way to work around the issue until it gets fixed upstream.

Related issues: https://github.com/liquibase/liquibase/issues/1755 https://github.com/liquibase/liquibase/issues/3260