-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better support for own pitest version #149
Comments
Thanks, I believe it should be relatively simple. I've done much the same with detekt, a static analyzer for Kotlin, which needed similar support from its Gradle plugin. I can't promise any timeline due to other commitments but I hope to knock it over within a week. |
@3flex Have you been able to progress with this, by any chance? I do some house cleaning and I could take it to the next release. |
I haven't yet, life got in the way unfortunately. I'd still like to see this change made - I'd be happy to work on it but can't commit to any timeline. If you want to pick it up that's no issue, just please let me know if you plan to so we don't double up on effort, thanks! |
@3flex Which commit in detekt do you refer to? |
While developing some enhancements for PIT itself, I learned that you maybe follow some sub-optimal route there.
I'd like to suggest doing it more like core plugins like for example JaCoCo plugin.
What you do is, you add a configuration to the root project build script configuration container and always fill there the pitest dependency configured via
pitestVersion
extensions property and provide thelaunchClasspath
property to extend the launch classpath.So if you want to use some version from maven local repository, you need to add the maven local repository to the rootproject buildscript repositories container in your settings script and then configure the
pitestVersion
. And if you need additional things on the launch classpath, you need to add them via the custom property.The more comfortable, standard and idiomatic way would be, to add the configuration to the normal projects configuration container where the plugin is applied with visibility set to false. And then to add via
Configuration#defaultDependencies
the dependency to the PIT version configured via the extension.This way one can easily add a repository to take versions from, can easily add libraries to the launch classpath the standard Gradle way without the need for the extra property, can easily use some compatible fork or whatever by simply configuring the pitest configuration as the standard dependency is only the default that is used when nothing is configured manually, ...
For reference you could basically look at alle the standard code quality plugins, or the JaCoCo plugin or probably some more. They all have
toolVersion
in their extension and then configure the default dependencies on the configuration they add to the normal project.The text was updated successfully, but these errors were encountered: