-
Notifications
You must be signed in to change notification settings - Fork 26
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
pitest-junit5-plugin doesn't support JUnit 5.10.x #106
Comments
For any future travelers that just want a quick fix to the problem, I've simply managed my JUnit version back down to 5.9.3 via the
|
What versions are you using of
Recent releases of the junit 5 plugin do not include shaded junit classes and should work with 5.10 without issue. |
Ah... upon closer inspection despite specifying I'll take another look at why I'm pulling in the wrong version of the JUnit plugin (I vaguely remember there being a bug with the Gradle plugin along these lines) and close this off when I eventually find alls well. |
It's indeed working when I force it to use the correct version of the JUnit plugin, so I'll close this off. There are 2 issues I'm encountering however:
I'll raise issues in gradle-pitest-plugin if I can figure out what's wrong. |
The support for it in Gradle was very tricky and it is an experimental feature. If you are able to debug the Gradle plugin to determine why it was not added or - even better - provide a small project to reproduce a problem, there is a chance to have it improved. |
Yes, but only in the Kotlin project and problematic to reproduce. Again, a small project as a reproducer, might help to find the problem. |
Btw, it's very strange. junit5 jars might be managed by something, but - unless you have some extra internal (company) plugin to manage the versions across the projects - I don't know why anything else could manager the pitest-junit5-plugin version... |
@szpak it turned out to be a bug on my end in my binary plugin. It wasn't actually trying to set the versions and leaving them to the old defaults. No need for concern, everything among the JUnit plugin, Gradle plugin, and PIT itself are working as expected. All's well, sorry for wasting everybodies time. |
No problem. Thanks for the update! |
Hey all,
I've got a handful of Gradle projects using SpringBoot and have bumped them to the latest versions (which is also managing the JUnit version up from 5.9.x to 5.10.x) only to find that it's broken PIT. I've done some sluething to figure out the problem, so for the sake of future travelers it starts here:
The method it can't find is this one. It was introduced in the 5.10 release, however the shaded JUnit classes within
pitest-junit5-plugin
are still on version5.9.2
and therefore predates those changes.Looking at the arguments being passed into PIT itself, my classpath looks like this:
My classpath contains its own JUnit 5.10.x dependencies because that's what I'm otherwise using to run my tests 'normally', however the shaded classes embedded into
pitest-junit5-plugin
are being picked up first. The mix of 5.10.x and 5.9.x is therefore causing me grief I presumably won't have if I move all my projects back down to 5.9.x.From what I understand PIT needs this JUnit plugin to be able to discover the tests (all that code lives in
org.pitest.junit5
) so I can't simply omit it to get everything working. Instead I need to drop myself back down to 5.9.x and wait for a 5.10.x compatible version of this plugin to be released.With that said, are there plans to release a new version of this plugin that supports 5.10.x?
What I'm seeing sounds similar to szpak/gradle-pitest-plugin#300, so apologies if I'm raising this in the wrong spot. The way PIT is split into the Gradle/Maven projects, this JUnit plugin, and PIT itself makes it difficult to pick the right one sometimes. One could maybe argue the heart of the issue is more to do with how the Gradle plugin is putting JUnit on the classpath even though it's already provided by the
pitest-junit5-plugin
. Ideally I would have thought this plugin wouldn't shade JUnit so bumping versions doesn't require actually re-releasing the plugin like it currently does.The text was updated successfully, but these errors were encountered: