Closed dcominottim closed 3 years ago
If wanted, you can use gradlew generateContractTests
on this sample project
cc @shanman190
I'll try to take a look at this here after a bit. Gradle's javaexec
is supposed to autoconvert for both Mac and Windows to handle the long paths problem, but it could possibly be that there is a quirk going on somewhere.
Actually, you can see in the info output that the class path was automatically shortened by using the jar manifest pattern.
C:\Program Files\RedHat\java-11-openjdk-11.0.8-2\bin\java.exe -Dfile.encoding=windows-1252 -Duser.country=US -Duser.language=en -Duser.variant -cp C:\Users\dcomi\AppData\Local\Temp\gradle-javaexec-classpath10323904499831617988.jar org.springframework.cloud.contract.verifier.TestGeneratorApplication "{\"testFramework\":\"JUNIT5\",\"testMode\":\"MOCKMVC\",\"basePackageForTests\":null,\"baseClassForTests\":\"com.xy.poi.ContractTestConfig\",\"nameSuffixForTests\":null,\"ruleClassForTests\":null,\"excludedFiles\":[],\"includedFiles\":[],\"ignoredFiles\":[],\"imports\":[],\"staticImports\":[],\"contractsDslDir\":\"C:\\Users\\dcomi\\IdeaProjects\\xy-poi\\build\\stubs\\META-INF\\com.xy\\xy_poi_app\\0.0.1-SNAPSHOT\\contracts\",\"generatedTestSourcesDir\":\"C:\\Users\\dcomi\\IdeaProjects\\xy-poi\\build\\generated-test-sources\\contractTest\\java\",\"generatedTestResourcesDir\":\"C:\\Users\\dcomi\\IdeaProjects\\xy-poi\\build\\generated-test-resources\\contractTest\",\"stubsOutputDir\":null,\"stubsSuffix\":\"stubs\",\"assertJsonSize\":false,\"includedContracts\":\".*\",\"includedRootFolderAntPattern\":\"**/\",\"packageWithBaseClasses\":null,\"baseClassMappings\":{},\"excludeBuildFolders\":false,\"failOnInProgress\":true}"
Running AdoptOpenJDK 11.0.8+10, ./gradlew clean generateContractTests
succeeds both on Windows 10 Enterprise 1809 and WSL v1 Ubuntu 20.04.2 LTS.
In the case of this particular application, there are no contracts and failOnNoContracts
is configured for false
, so the TestGenerator
code should noop and at least for me using the dcominottim/xy-inc project appears to be doing just that in both the cases that I'm using. I'll try to see if I can recreate the issue on my 20H2 personal device later this evening.
Ok, so on my personal Windows 10 Home 20H2 I am also having a successful run of the above command. It should be noted that clean
is not strictly necessary, but I'm wanting to ensure that multiple runs actually perform the task execution rather than taking advantage of Gradle's up to date checks.
Environment: OS: Windows 10 Home 20H2 Java: AdoptOpenJDK 11.0.8+10 Gradle: <using Gradle wrapper included with project; 6.7.1>
So you can't reproduce it @shanman190 ?
I’ll double test this when I get home in a couple hours and will provide the results.
Em ter., 2 de fev. de 2021 às 09:17, Marcin Grzejszczak < notifications@github.com> escreveu:
So you can't reproduce it @shanman190 https://github.com/shanman190 ?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/spring-cloud/spring-cloud-contract/issues/1600#issuecomment-771596024, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFPYONPEYB46FLUJYTEVFLS47UO3ANCNFSM4WJDG7QA .
@marcingrzejszczak, you are correct. Using the example provided I am not able to reproduce the error on the systems available to me.
@shanman190, sorry about a little mistake from my part -- the generateContractTests
task was temporarily passing because of adjustments I had made to bypass the problem (adding failOnNoContracts=false
and removing all test contracts, so that there was nothing to do). Can you please do a git pull from main and re-test now? It's breaking again now that I've re-added a .kts contract test file.
Commit 808d2e8b3e03a96e3af04bdeb438fda94c7bae75
.
Ok, getting a bit deeper into this. The TestGenerator
is throwing this error, but since we're using javaexec it's not being bubbled up the best.
@marcingrzejszczak, I'll have a PR coming at the very least to cover an edge case where if javaexec exits with a status code of 1, that we'll still be able to output the stdout/stderr of the process to the debug log before throwing the exception up the stack further.
Exception in thread "main" java.lang.NoSuchFieldError: PUBLIC
at org.jetbrains.kotlin.scripting.resolve.ScriptProvidedPropertiesDescriptor.<init>(ScriptProvidedPropertiesDescriptor.kt:34)
at org.jetbrains.kotlin.scripting.resolve.LazyScriptDescriptor$scriptProvidedProperties$1.invoke(LazyScriptDescriptor.kt:267)
at org.jetbrains.kotlin.scripting.resolve.LazyScriptDescriptor$scriptProvidedProperties$1.invoke(LazyScriptDescriptor.kt:57)
at org.jetbrains.kotlin.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:375)
at org.jetbrains.kotlin.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:494)
at org.jetbrains.kotlin.scripting.resolve.LazyScriptDescriptor.getScriptProvidedProperties(LazyScriptDescriptor.kt:270)
at org.jetbrains.kotlin.scripting.resolve.LazyScriptClassMemberScope$scriptPrimaryConstructor$1.invoke(LazyScriptClassMemberScope.kt:49)
at org.jetbrains.kotlin.scripting.resolve.LazyScriptClassMemberScope$scriptPrimaryConstructor$1.invoke(LazyScriptClassMemberScope.kt:21)
at org.jetbrains.kotlin.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:375)
at org.jetbrains.kotlin.scripting.resolve.LazyScriptClassMemberScope.resolvePrimaryConstructor(LazyScriptClassMemberScope.kt:80)
at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope$primaryConstructor$1.invoke(LazyClassMemberScope.kt:175)
at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope$primaryConstructor$1.invoke(LazyClassMemberScope.kt:50)
at org.jetbrains.kotlin.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:375)
at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope.getPrimaryConstructor(LazyClassMemberScope.kt:493)
at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope.getConstructors(LazyClassMemberScope.kt:488)
at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassDescriptor.getConstructors(LazyClassDescriptor.java:405)
at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassDescriptor.resolveMemberHeaders(LazyClassDescriptor.java:605)
at org.jetbrains.kotlin.resolve.LazyTopDownAnalyzer.resolveAllHeadersInClasses(LazyTopDownAnalyzer.kt:239)
at org.jetbrains.kotlin.resolve.LazyTopDownAnalyzer.analyzeDeclarations(LazyTopDownAnalyzer.kt:212)
at org.jetbrains.kotlin.resolve.LazyTopDownAnalyzer.analyzeDeclarations$default(LazyTopDownAnalyzer.kt:60)
at org.jetbrains.kotlin.scripting.compiler.plugin.repl.ReplCodeAnalyzerBase.runAnalyzer(ReplCodeAnalyzer.kt:124)
at org.jetbrains.kotlin.scripting.compiler.plugin.repl.ReplCodeAnalyzerBase.doAnalyze(ReplCodeAnalyzer.kt:133)
at org.jetbrains.kotlin.scripting.compiler.plugin.repl.ReplCodeAnalyzerBase.analyzeReplLine(ReplCodeAnalyzer.kt:106)
at org.jetbrains.kotlin.scripting.compiler.plugin.repl.GenericReplCompiler.compile(GenericReplCompiler.kt:81)
at org.jetbrains.kotlin.cli.common.repl.GenericReplCompilingEvaluatorBase.compileAndEval(GenericReplCompilingEvaluator.kt:38)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase$compileAndEval$1.invoke(KotlinJsr223JvmScriptEngineBase.kt:64)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase$compileAndEval$1.invoke(KotlinJsr223JvmScriptEngineBase.kt:26)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.asJsr223EvalResult(KotlinJsr223JvmScriptEngineBase.kt:90)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.compileAndEval(KotlinJsr223JvmScriptEngineBase.kt:63)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.eval(KotlinJsr223JvmScriptEngineBase.kt:33)
at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249)
at org.springframework.cloud.contract.spec.internal.KotlinContractConverter$convertFrom$eval$1.invoke(KotlinContractConverter.kt:50)
at org.springframework.cloud.contract.spec.internal.KotlinContractConverter$convertFrom$eval$1.invoke(KotlinContractConverter.kt:31)
at org.springframework.cloud.contract.spec.internal.KotlinContractConverter.withUpdatedClassloader(KotlinContractConverter.kt:68)
at org.springframework.cloud.contract.spec.internal.KotlinContractConverter.convertFrom(KotlinContractConverter.kt:46)
at org.springframework.cloud.contract.verifier.file.ContractFileScanner.tryConvert(ContractFileScanner.groovy:308)
at org.springframework.cloud.contract.verifier.file.ContractFileScanner.addContractToTestGeneration(ContractFileScanner.groovy:286)
at org.springframework.cloud.contract.verifier.file.ContractFileScanner.appendRecursively(ContractFileScanner.groovy:253)
at org.springframework.cloud.contract.verifier.file.ContractFileScanner.findContractsRecursively(ContractFileScanner.groovy:221)
at org.springframework.cloud.contract.verifier.TestGenerator.generateTestClasses(TestGenerator.java:132)
at org.springframework.cloud.contract.verifier.TestGenerator.generate(TestGenerator.java:112)
at org.springframework.cloud.contract.verifier.TestGeneratorApplication.main(TestGeneratorApplication.java:40)
@dcominottim Ok, so this appears to be a conflict introduced as a little bit of a break I think on the Jetbrains side. So the Kotlin runtime suite is very finicky when it comes to version alignment. In this particular case, SC-contract-spec-kotlin includes Kotlin 1.4.0 as the default version. Most everything in the project gets upgraded to Kotlin 1.4.21 via the kotlin("jvm")
defined in the build script, but one of the modules used by SC-contract-spec-kotlin does not have it's version affected.
As a workaround, you can do the following to correct the version misalignment:
dependencies {
// Upgrade kotlin-scripting-compiler-embeddable to be aligned with your current Kotlin version
contractTestImplementation("org.jetbrains.kotlin:kotlin-scripting-compiler-embeddable:1.4.21")
}
Due to this version misalignment, it's resulting in your project getting the NoSuchFieldError
described above.
@dcominottim unrelated to your issue, but just fyi that the buildscript block is no longer necessary for SC-contract. Specifically in your case the spec-kotlin is now pulled from the standard dependencies. :)
@marcingrzejszczak, with respect to this bug, what do you think about a specific docs update that shows adding spec-kotlin
and the synced version of kotlin-scripting-compiler-embeddable
? I think this is about the best thing that we can offer presently given the circumstances.
Another possibility, though I don't know the feasibility, is to see if there is some way to use the kotlin-compiler-embeddable
directly instead of via the kotlin-scripting-compiler-embeddable
library. I'm not familiar with the Kotlin compilation process exactly. If this were possible, then kotlin-compiler-embeddable
is automatically upgraded with the inclusion of kotlin("jvm")
.
@marcingrzejszczak, with respect to this bug, what do you think about a specific docs update that shows adding spec-kotlin and the synced version of kotlin-scripting-compiler-embeddable? I think this is about the best thing that we can offer presently given the circumstances.
I'm all for it
Another possibility, though I don't know the feasibility, is to see if there is some way to use the kotlin-compiler-embeddable directly instead of via the kotlin-scripting-compiler-embeddable library. I'm not familiar with the Kotlin compilation process exactly. If this were possible, then kotlin-compiler-embeddable is automatically upgraded with the inclusion of kotlin("jvm").
I'll try to summon @sdeleuze for help and his opinion.
Describe the bug The
generatedContractTests
fails with an error on Gradle 6.7.1. I am using the Kotlin DSL plugin (all things Spring Cloud Contract are 3.0.0), Kotlin 1.4.21, and JDK11 (from RedHat). Happens on both Linux (Ubuntu 20.04.1) and Windows (20H2).Sample
Output from gradlew generateContractTests --info