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