We lose all these mutators because of the mutators removed by default in PIT?

Looks like it, yes. We did lose a lot of mutations operators (seeMutations.java,MutatorApiOfPitTest.java andthe list of research mutators). That being said I believe we should take some time to make sure I didn't miss something while upgrading.

@echebbi So creating a new bundle forhttps://github.com/pitest/pitest-rv-plugin and adding it to our distribution would bring the old mutators back?

Yes, just like we did for thepitest-junit5 plugin. Do you think that we should integrate thepitest-rv plugin after all?

@echebbi maybe we should/could. I'm a bit worried by the fact that people using Pitclipse would have more mutators than those using Maven and ignoring the newpitest-rv, but maybe we can rely on them knowing the Maven plugin as well.

By default we run Pitest's DEFAULT mutator group so our mutators set would still be the same as a bare Pitest configuration.pitest-rv's mutators would only be exposed through the preferences/configuration pages which feels fair to me.

We can even add a column to the mutators table that explicitely states the origin of each mutator:

@echebbi yes that'd be useful; but would such information be easily (automatically) retrieved and easy to maintain?

Moreover, withpitest-rv we would restore the "old defaults" or not?

would such information be easily (automatically) retrieved and easy to maintain?

It might be possible to retrieve/infer the information through reflection. My intuition is that since we have access to theMethodFactoryFactory instances (each mutation operator is implemented as a child ofMethodMutatorFactory) we should be able to get the info with something along the lines of:

// maps plugin ID to the name we want to display in the table//Map<String,String>pluginIdToContributorName =Map.of("org.pitest","pitest","org.pitest.pitest-rv-plugin","pitest-rv");Collection<MethodMutatorFactory>mutators =ServiceLoader.load(MethodMutatorFactory.class,IsolationUtils.getContextClassLoader());for (MethodMutatorFactorymutator :mutators) {//// retrieve the contributor through reflection//Bundlebundle =FrameworkUtil.getBundle(mutator.getClass());//// update our 'Mutators' enum with the contributor name//StringcontributorName =pluginIdToContributorName.get(bundle.getBundleId());Mutators.valueOf(mutator.getName()).setContributorName(contributorName);}

Or, if we want to be really extensible it should be possible to craft a solution based on a custom extension point so that external plug-ins can provide new mutators without having to change a single piece of code in Pitclipse's core. That would require some refactoring though so I believe that such a work would deserve its own PR.

Moreover, with pitest-rv we would restore the "old defaults" or not?

We wouldn't because this group is not related to the research operators and has been completely removed. We may want to somehow supportthe groups related to research operators though.

@echebbi thanks for the clarification, especially about the old defaults, which are now gone for good. I thought thepitest-rv was related to that so I was reluctant to addpitest-rv right away because that would have required to undo the removal of old defaults, but it's not like that :)

So, shall we addresspitest-rv in a new PR and go on with this one?

I would also try to build with Java 21 and have a UI test with Java 21, but we can do that in another PR as well.

shall we addresspitest-rv in a new PR and go on with this one?

@LorenzoBettini fine by me!