Skip to content
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

Open
Vampire opened this issue Oct 1, 2019 · 6 comments
Open

Better support for own pitest version #149

Vampire opened this issue Oct 1, 2019 · 6 comments

Comments

@Vampire
Copy link
Contributor

Vampire commented Oct 1, 2019

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 the launchClasspath 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.

@3flex
Copy link
Contributor

3flex commented Feb 28, 2020

@szpak would you be open to a PR for this (and #151)?

I'm facing similar issues while trying to debug pitest Junit 5 integration as I'd like to see it work with Spek (a Kotlin based Junit 5 engine).

@szpak
Copy link
Owner

szpak commented Mar 1, 2020

@3flex As it also seems to generate a warning in Gradle 6, so I planned to take a look at removing configuration from the root project anyway. If you would like to provide a PR which solves all relates issues, it would be nice.

@3flex
Copy link
Contributor

3flex commented Mar 1, 2020

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.

@szpak
Copy link
Owner

szpak commented Mar 27, 2020

@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.

@3flex
Copy link
Contributor

3flex commented Mar 29, 2020

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!

@szpak
Copy link
Owner

szpak commented Apr 9, 2020

Thanks, I believe it should be relatively simple. I've done much the same with detekt,

@3flex Which commit in detekt do you refer to?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants