Re-run the license task on the project configurations/dependencies ch…

[sergeys-opera]

…anges

The idea is simple - as the license task depends on the Gradle build script itself
let's mark the build script as the task input.

A slight drawback of this approach is that the license task will re-run after every
build script change, i.e. it will be UP-TO-DATE less often. But changing the build
script should not happen that often compared to the code changes and Gradle would
need to re-configure the project anyway during the next build so re-running the license
task should be acceptable.

An alternative approach could be to declare all project properties that affect
the task outcome as inputs to the task.

Closes #212.

[jaredsburrows]

@sergeys-opera Does this "cache" the buildFile itself? What happens if someone is using a dependencies.gradle(.kts) or libs.versions.toml?

[sergeys-opera]

Does this "cache" the buildFile itself?

Yes.

What happens if someone is using a dependencies.gradle(.kts) or libs.versions.toml?

Hm, I haven't really thought about it.
In many cases it's not an issue though as you would need to add a new dependency to the module's build.gradle file anyway regardless of whether you use libs.versions.toml or not and, thus, you would need to modify the build file.
The problem might occur if you add dependencies dynamically in the external script file or if a library changes its license in a new version (then update of a version stored libs.versions.toml wouldn't trigger the re-run of the task).

So my fix is not optimal, however it's much better than the current broken logic.

The proper fix would be to declare the project configurations and dependencies as input properties of the license task.

[jaredsburrows]

Lets' merge this for now. Thanks!

[jaredsburrows]

@sergeys-opera Feel free to try out the snapshot to test it locally :)