Concurrency issue when running multiple HtmlSanityCheck tasks in parallel

[thc202]

When running Gradle with --parallel flag and with multiple subprojects configured with HtmlSanityCheck it might happen that the configurations of one subproject end up being used by other, for example:

> Task :addons:alertFilters:htmlSanityCheck
/zap-extensions/addons/alertFilters/src/main/resources

> Task :addons:browserView:htmlSanityCheck
/zap-extensions/addons/alertFilters/src/main/resources

BUILD SUCCESSFUL in 39s
96 actionable tasks: 4 executed, 92 up-to-date

(The plugin was tweaked to print the source being used, to show the issue more easily.)

The second task :addons:browserView:htmlSanityCheck should be using its own source directory (/zap-extensions/addons/browserView/src/main/resources) instead of the one from the other subproject.

From an initial investigation this seems to be caused by the Configuration being a singleton, so configurations set by one task might be used/overridden by others.

[gernotstarke]

oops - I just recently re-implemented Configuration to be a Registry & Singleton to avoid having to pass around config-instances all over the code...

Didn't take that kind of parallel usage into account - any idea for a resolution?

[gernotstarke]

Seems we have to bite the bullet and refactor to configuration INSTANCES instead of a REGISTRY again. I'll try that on a branch off 1.0.0-RC-2.

[thc202]

If it's fine adding other dependencies to the plugin (Guice?), with dependency injection maybe? It would not require passing the configuration around (not explicitly/manually at least).

[gernotstarke]

@thc202, could you possibly supply a regression test for it? The class 'HtmlSanityCheckTaskFunctionalTest' might provide an idea...

I'm currently refactoring Configuration back to instance-based (instead of registry-based).

[gernotstarke]

should be fixed with 1.0.0-RC-2, which I just published to gradle plugin portal... could you please verify? thx