JDK-8 support #7
Comments
|
Thanks for the report! The problem is in fact with old The problem is that a mechanism in the plugin which allows to change default PIT version doesn't work properly and even though it passes to PIT good (overridden) version the default version do the plugin is used. For 0.32.0 it was 0.32 which doesn't support Java 8 bytecode (has old embedded As a workaround I uploaded gradle-pitest-plugin 0.33.0-SNAPSHOT (available in Sonatype snapshot repository) which fixes your problem (by using 0.33 as a default version). I will release 0.33.0 when I fix the core problem with dependencies. Btw, I tested the plugin with Java 8 before 0.33 was released, but I was using the new snapshot version which had PIT 0.33 set as a default version :). |
|
Thanks for your reply. I just tested against the SNAPSHOT version of the plugin and everything works fine! Good work so far. As I am using this for production code, when do you think will 0.33.0 plugin be released? |
|
There is a problem with the classpath which is used to call a static bootstraping method in PIT from my plugin and a classpath which PIT uses to set up its deamons/workers. It is possible to use PIT 0.33 with gradle-pitest-plugin 0.32.0 with the following configuration: but I would like to allow user to just define requested version in pitestVersion parameter (which is something I am working on, but currently only with various problems and I'm not sure if it would be possible without writing a custom class loader to bootstrap PIT...). |
|
I have tried your workaround, and the build succeeds, but now I am getting an exception during the test run. That did not happen with the SNAPSHOT plugin version. I am also wondering why the build does not break. I will provide the stack trace for further analysis. For the moment, I will fallback to the SNAPSHOT plugin. |
|
Hm, the last comment is not fully correct. I recognised a small miss configuration of my build script. Still, a clean 0.33.0 plugin release is pretty much appreciated :-). |
This allows to launch PIT with custom classpath containing the PIT version defined by the user using pitestVersion parameter. PIT is no longer a compile time dependency of the plugin
|
I evaluated a few possible solutions (including Gradle internal classes) and at the end after a consultation with Peter Niederwieser I decided to use JavaExec task which launches PIT as a separate Java process (with a separate classpath) what fixes an ability to override PIT version. There is a new Btw, the another solution would be needed to support |
|
Btw, for consistency I changed also |
|
Hey szpak, I just tried it and it works so far. Thanks a lot. This is the configuration I am using currently. ext {
pitestPluginVersion = "0.33.0-SNAPSHOT"
}
buildscript {
dependencies {
classpath("info.solidsoft.gradle.pitest:gradle-pitest-plugin:" + pitestPluginVersion)
}
}
pitest {
threads = 6
}I am getting some errors printed to the console when running, but the test suite runs through: From my side, the release can be made. |
|
Okay I have to correct myself. The plugin SNAPSHOT Version breaks mit 'bootRun' task. I have to dig deeper into it to provide some more details on that. |
|
Finally I had to revert back to plugin version 0.32.0. The error that occurred is very weird. With the following configuration, everything works fine, I can execute pitest and bootRun tasks without problems: buildscript {
repositories {
maven { url "https://ci.it.ewerk.com/nexus/content/groups/public" }
}
dependencies {
classpath "org.springframework.boot:spring-boot-gradle-plugin:1.0.1.RELEASE"
classpath("info.solidsoft.gradle.pitest:gradle-pitest-plugin:0.32.0") {
exclude group: "org.pitest"
}
classpath "org.pitest:pitest-command-line:0.33"
}
}Using the following configuration breaks my build: buildscript {
repositories {
maven { url "https://ci.it.ewerk.com/nexus/content/groups/public" }
}
dependencies {
classpath "org.springframework.boot:spring-boot-gradle-plugin:1.0.1.RELEASE"
classpath("info.solidsoft.gradle.pitest:gradle-pitest-plugin:0.33.0-SNAPSHOT") {
exclude group: "org.pitest"
}
classpath "org.pitest:pitest-command-line:0.33"
}
}Executing the pitest tasks still works without problems, but when I execute the bootRun (Spring Boot porject) task, the embedded jetty launches up without problems, but it does not serve static resources any more. I have no clue if this is a problem of the spring-boot or the pitest plugin. In the end they should not interfere with each other at all. Did I misconfigure something? |
|
Thanks for your feedback and sorry for a late reply. I haven't got any email notification about your last 3 comments... I tried to reproduce problem you mentioned with Getting Started Spring Boot application, but with no luck. Do you have anything special in your Spring Boot application? Maybe you would be ale to enhance the original sample app to reproduce the problem with bootRun? Regarding the first error about |
|
Regarding the I think there is no need to follow this one up any more, sorry for mixing the tickets. |
|
To come back to the original issue, yes of course my spring boot app is "special". And yes, the problem is ONLY related to static resources, controllers work as expected. I will give it a shot with the example app and try to enhance it until the problems occurs. I will come back with feedback as soon as possible. |
|
I have put together a example project that shows the issue: https://github.com/lando/spring-boot-pitest The problem is described within the |
|
Thanks lando! I will take a look at it tonight. |
|
Please run the project with a JDK-8. Here is my concrete version. |
|
Your project was really helpful. I tried to run it with openjdk-1.8.0.5 and it fails in more spectacular way :). This helped me to focus on classpath issue and it seems I have found the reason of my situation (which probably causes also your problems). spring-boot-gradle-plugin takes any JavaExec task in the build and tries to execute it. Before the execution the task is modified to support dynamic reloading and some other spring-boot features which causes that pitest task (which in my case was run first on bootRun) tries to setup the Spring context. I reported issue #721 with a solution proposal (I'm not sure what they wanted to achieve). Unfortunately this makes version 0.33.0 not usable in spring-boot application (at least until they modify their plugin). Luckily PIT 0.33 with a workaround can be used with 0.32.0 which I will add to README. |
|
Thanks for your work. I will watch the spring-boot issue. |
|
As 0.33.0 provides native support for PIT 0.33 and Java 8 I'm closing this issue. I created #11 to keep users informed. |
Hey,
I am using the gradle-pitest-plugin under JDK-8 with Gradle-1.11. Here is my declaration from build.gradle:
buildscript { repositories { mavenCentral() } dependencies { classpath 'org.springframework.boot:spring-boot-gradle-plugin:' + springBootVersion classpath 'info.solidsoft.gradle.pitest:gradle-pitest-plugin:0.32.0' } } pitest { //dependencies { // compile 'org.ow2.asm:asm:5.0' //} pitestVersion = "0.33" }The test execution fails with the following exception:
I already read some blog posts and it seems like this problem relates to an invalid ASM library. I tried to declare a dependency directly to the pitest task but that does not help. On my default class path there is an ASM library version 3.3.1 because of a transitive dependency of QueryDSL.
I noticed that the 'pitest' classpath does not include a specific ASM version.
Any advice would be pretty much appreciated.
The text was updated successfully, but these errors were encountered: