KotlinParser does not get configured with the current runtime classpath

[abstratt]

At least in tests, the Kotlin parser is not configured with the runtime classpath as the Java parser is, so types are not resolved.

I ended up having to this in my test for a Kotlin recipe test:

rewriteRun(
            Assertions.kotlin(
               before,
                after
            ) {
                // or else, the parser will have no classpath available
                (it.parser as KotlinParser.Builder).classpath(JavaParser.runtimeClasspath())
            }
        )

A similar Java recipe test does not need that. Is that by design? I am assuming this is a test-time only issue, and when running the recipe via rewriteRun task, the Kotlin parser does get a proper classpath configured.

[timtebeek]

Thanks for reaching out @abstratt ! I must admit I'm not fully up to date on our Kotlin support. Perhaps @knutwannheden can provide some more details about the expected usage & patterns here. From what you've shown it does make sense for Kotlin text blocks to be able to access types from both Kotlin and Java by default, with explicit classpath only necessary when additional libraries are used.

[shanman190]

Unless I'm mistaken somewhere, the default classpath for all parsers is the JDK itself and (maybe) any applicable language specific compiler tools. Anything extra has to be added via the classpath for a parser, usually done in the test class defaults OR the test method defaults.

https://docs.openrewrite.org/authoring-recipes/recipe-testing#specifying-the-classpath-for-dependencies

In the build plugins, the classpath is injected into each of the parsers explicitly.

[abstratt]

Thanks for the replies, folks.

From what I understood, org.openrewrite.java.Assertions builds the JavaParser test fixture with the classpath returned by JavaParser.runtimeClasspath():

rewrite/rewrite-java/src/main/java/org/openrewrite/java/Assertions.java

Line 137 in ed81f42

.classpath(JavaParser.runtimeClasspath())

This commit introduced that:

b5a9f6d

org.openrewrite.kotlin.Assertions does not do any customization of the classpath by default. Luckily, one can do so via the parser builder customization function (Consumer<SourceSpec<K.CompilationUnit>> spec) parameter, as shown above.

If that is the case, maybe the same should be done for other JVM-based parser builders?

[shanman190]

After a short discussion with Sam, we couldn't find any downsides of going ahead and bootstrapping the parsers (Groovy and Kotlin) with the current runtime classpath.

701f7b2

Next up will be to update the documentation as it was already out of alignment anyway.

[abstratt]

Thanks, folks. So far, having a good experience exploring OpenRewrite. For some context, we are exploring the idea of adopting it in the Gradle Build Tool to migrate builds between Gradle releases:

gradle/gradle#32738 (comment)

Your input is much welcome, by the way.

[timtebeek]

Great to read that you're considering further automating Gradle upgrades; happy to help towards those efforts any way we can.