Refactorings that may break plugin compatibility #923
Conversation
MethodName has existed for several years, but has not acquired any behaviour. It results in method chains accessing the underlying string and provides only marginal benefit at best. Removing it will break some third party plugins. Version number should reflect this on release.
since mutating static initializer code is no longer supported, and detection of static initialisers has been concentrated into an interceptor, poison status is no longer required.
Concentrates tracking of finally blocks into single interceptor, removing the need to pass a boolean flag around. Check that we are handling a duplicate mutant (and not just similar mutants on the same line) is made slighly more lenient by including the mutator description when checking equality.
|
It ran it with the functional tests in gradle-pitest-plugin and it all passed (except non-related hcoles/pitest-plugins#2 and hcoles/pitest-plugins#4). Just writing this comment, I realized that you were writing about the other PIT plugins :). |
|
Thanks @szpak you've done a lot more checking than I've done. The idea here was to clean up and simplify a few things that have been bugging me for a while that requires changes to classes used in various interfaces. The boundary of where the plugin api starts and ends isn't very well defined, but it is possible that the changes will break something somewhere so will come with a version bump to 1.7.0. Fortunately there aren't that many plugins out there. Since the version is going to be bumped I may make some other breaking changes in the 1.7.0 release that might affect the gradle plugin. Only thing that comes to mind at the moment is stripping out some of the defunct parameters, but it is possible there might be other changes. |
No description provided.