jGiven html report generation failure - incompatible with openAPIGenerator

[manoj-fd]

I am trying to run jGiven test with version 1.2.2 and Gradle 7.4.2, encountering below issue while html report generation. Error

**Execution failed for task ':service:jgivenAcceptanceTestReport'.

Class com.tngtech.jgiven.impl.util.FilePredicates$1 does not implement the requested interface java.util.function.Predicate**

Note - if i remove openapi-generator related task, the report generation works fine
build.gradle file

dependencies {
classpath "com.tngtech.jgiven:jgiven-gradle-plugin:1.2.2"
classpath "org.openapitools:openapi-generator-gradle-plugin:6.0.0"
}

subproject{
dependencies {
testImplementation 'com.tngtech.jgiven:jgiven-junit:1.2.2'
testImplementation 'com.tngtech.jgiven:jgiven-core:1.2.2'
testImplementation 'com.tngtech.jgiven:jgiven-html5-report:1.2.2'
}

apply plugin: 'com.tngtech.jgiven.gradle-plugin'
acceptanceTest.finalizedBy jgivenAcceptanceTestReport

}

[l-1squared]

Dear manoj,
first off, sorry for not reaching out to you sooner. Unfortunatley I was sick and did not have the capacity to look after JGiven.

Concerning your issue: This is really odd. My first guess would be that the openapi package overwrites something important on the classpath. However, I am unsure why this would break a java util dependency of all things.

I'll try to reproduce the issue.

As an aside, have you tried updating the gradle version? We once encountered strage errors, when using an outdated one.

[l-1squared]

Well, turns out that "FilePredicate$1" indeed does not implement java.util.function.Predicate. (we still used googles functional api within a Stream here. (see PR).
I still don't know why the presence of openapo off all things makes the build fail, though.
I still need to verify that we actually fix the issue with the change and then I will release an update

[l-1squared]

After analyzing this waaay to thoroughly, I actually think that the following happens:
We use google.guava function, which was changed (addition of an annotation between v30 and v31). We compiled it with v30. Now the addition of the openapi-tools to the classpath replaces that by a version 31 (here is the biggest hole, because the openapi tools pom states that they are using v30 as well...) of guava. Since the bytecode changed, we get an IncompatibleClassChange error in the presence of of openapi and openapi only.

Why do I prefer this explanation to my previous one? 1.) Everything worked without openapi, 2.) The current master produces a green build 3.) The descritpion for the error type IncompatibleClassChangeError states that this error happens when a class definition changed between compile and runtime.

Anyhow, I will merge the PR and then produce a new release in time.