fix: input property fingerprinting

[nbrugger-tgm]

replace a "hardcoded/real" property with a gradle style one so gradle can actually use the input as such

Closes: #120

[nbrugger-tgm]

@stevesaliman

[nbrugger-tgm]

@MalloD12

[stevesaliman]

The next release of the plugin is going to use the Liquibase Command API instead of a JavaExec, so this PR may not be needed anymore.

I'm just waiting on a fix in Liquibase, which will hopefully be in the next LB release.

[kevin-atx]

@stevesaliman - the command API fix will be released with Liquibase 4.28.0 on 5/21/2024 (today). Starting with this release, you should be able to re-implement the Gradle plugin to take advantage of the command API.

[kevin-atx]

@stevesaliman - were you able to test with the 4.28.0 release of Liquibase to see if this PR is still needed?

[stevesaliman]

Unfortunately, version 4.28.0 still has an issue with changelog parameters and the Command API, so I can't finish my testing.

[MalloD12]

Hey @stevesaliman, could you please point us to the changelog parameters issue you are seeing?

Thanks,
Daniel.

[stevesaliman]

The issue is in how the Gradle plugin interacts with the new CommandScope API. When a task executes, it creates a new ChangelogParameters object to store any parameters given to it by Gradle before calling CommandScope.execute. Since there is no database connection at this point, the database is null, so the database filters are also null.

I set a breakpoint in the ChangeLogParameters constructor and in Liquibase 4.20.0, the constructor would be called by the Gradle plugin before calling execute, but it would be called again after calling execute, this time with a database. The Groovy DSL's parse method would then be given parameters with all the parameters and databaseFilters.

But in 4.21.0, the constructor is only called once, and the the parameters made by the plugin are the parameters given to the parse method. Since the database is null, it isn't properly handling ChangeLogParameters that had the dbms attribute set.

I'm not sure what changed from 4.20 to 4.21, but something change that gets in the way of the changelog parameters working, and I haven't figured out how to work around it yet.

[stevesaliman]

The next version of the plugin will not be able to use the command API, because the changelog parameter issue remains. So LiquibaseTasks will continue to be JavaExec tasks, and your fix will likely need to be implemented in the new code.

I pushed the cli-api branch with the new code if you want to take a look. It shouldn't be too hard to make the required changes to that branch before it gets released.

[stevesaliman]

The LiquibaseCommand class is no longer part of the plugin, as of version 3.0.0, so this PR is no longer needed.