My plugin gradle-pitest-plugin - in general - has only runtime dependency on pitest.jar (pitest-entry to be precise). It is nice as user can configure any PIT version in the plugin configuration and runtime configuration is added before pitest task execution which itself is called with ExecTask (the releases of my plugin are not always synced with the upstream releases).
However, there is an ongoing effort to add support for report aggregation, using a dedicated pitest-aggregator module (which itself depends on pitest-entry). That new aggregation plugin (packaged together with the main one) uses classes from pitest-aggregator directly which complicates an ability to easily change PIT version.
My first idea was to use compileOnly for pitest-aggregator to make the code compile and - based on user configuration - add runtime dependency during execution (possibly with other, but still compatible jar version). Unfortunately it fails on the configuration phase (of the project that uses the aggregation plugin):
|* What went wrong:
|A problem occurred configuring root project 'should-aggregate-report-from-subproject'.
|> Could not create task ':pitestReportAggregate'.
| > Could not create task of type 'AggregateReportTask'.
| > Could not generate a decorated class for type AggregateReportTask.
| > org/pitest/mutationtest/config/ReportDirCreationStrategy
It seems that my work to add a dependency is done too late.
Question. It is possible to add a plugin dependency for the configuration phase in the plugin itself dynamically at the end-project execution?
If not, how would you propose to deal with the case that I want to operate with real classes from JAR, but still want to defer the dependency version resolution for end-project configuration/execution (not to the classic dependency in pom.xml - which overrides is problematic especially with the plugins {} syntax)? By packaging the other plugin as a separate JAR?