Some special properties about liquibase-gradle-plugin HOT 2 CLOSED

The Liquibase Maven plugin appears to have a different source file for each target the plugin supports. Each target can then do whatever it wants to do before invoking Liquibase itself. It is worth noting that the Maven plugin is part of the core Liquibase repository, and maintained by the same person.

The Gradle plugin took a different approach. My goal was to have the plugin be a thin wrapper around the command line execution of Liquibase. I wanted to simply pass through any elements of an activity to Liquiabse with as little processing as possible. If Liquibase ever adds or changes command line options, users could simply fix their build.gradle files. No plugin release would be required.

I don't think having 2 different activities is that ugly - one activity is used for changing a single database, and the second involves multiple databases. The property duplication can be minimized by using Gradle properties, like your example does with the changeLogFile.

I'm not completely opposed to adding this, but I want to minimize the amount of work that would need to be done, and the number of things that need to be checked when new versions of Liquibase are released.

from liquibase-gradle-plugin.

Makes totally sense what you say. It is not that ugly but at first I found it quite confusing if you configure e.g. excludeObjects the execution will fail for certain liquibase commands that don't support it. So I am ok to with the current approach and of course there is still some optimization possible on our side. So lets close it and maybe revisit it if needed.

from liquibase-gradle-plugin.