Tweak javac parser for kotlin-maven-plugin

[seanf]

No description provided.

[uhafner]

Wouldn't it be more user friendly if you create a new parser with the name and icon "Kotlin Compiler"? You still can derive from the Java parser (new constructor required).

[seanf]

Well, I think it could go either way. The "javac" parser seems to be fairly forgiving already, and kotlin-maven-plugin's messages are almost identical to the "javac" format, except for the use of parentheses instead of square brackets, plus an extra couple of spaces. The regex doesn't mention ".java" (or ".kt"), so it's not really tied to the Java compiler as such.

I think a lot of code bases will have have a mixture of Java and Kotlin, so not having to run two separate parsers (javac plus Kotlin) may have a slight performance benefit for large build logs, plus it's one less thing you have to think of when switching a project from Java to Java+Kotlin.

Part of the problem is that it's hard to convey to the user exactly what the parser is capable of in a name. (I was fooled by the Eclipse parser until I realised that it wasn't picking up my particular compiler toolchain's messages). I must confess I'm still not clear on the difference between the parser ID and parser name. It seems like the Jenkins pipeline step needs a parser name, whereas I would have expected it to use parser ID (which doesn't care about locales).

Anyway, I can do as you suggest if you prefer, although I'm not sure what the right parser name would be. I only know that this format is produced by kotlin-maven-plugin and that it almost emulates "javac". The command-line compiler kotlinc uses a different, multi-line, format[1]. I haven't checked kotlin-gradle-plugin, but I think calling the parser "Kotlin Compiler" would be misleading, and calling it "kotlin-maven-plugin" might be too limiting. What compiler ID would you prefer?

[1]

hw.kt:1:1: warning: expected performance impact of inlining 'public inline fun main(args: Array<String>): Unit defined in root package' can be insignificant. Inlining works best for functions with lambda parameters
inline fun main(args: Array<String>) {
^

[seanf]

I thought I'd collect another data point or two for Gradle (Kotlin and Java compilation):

On stdout for Kotlin:

w: C:\Users\Sean\Documents\GitHub\hellokt\src\main\java\hw.kt: (1, 1): Expected performance impact of inlining 'public inline fun main(args: Array<String>): Unit defined in root package' can be insignificant. Inlining works best for functions with lambda parameters

And on stderr only (ref: https://issues.jenkins-ci.org/browse/JENKINS-35373 and gradle/gradle#1275):

C:\Users\Sean\Documents\GitHub\hellokt\src\main\java\Dummy.java:14: warning: [deprecation] stop() in Thread has been deprecated
        Thread.currentThread().stop();
                              ^

So kotlin-gradle-plugin looks almost identical to kotlin-maven-plugin (and thus "javac"), except that it starts with w: instead of [WARNING] , and it has an extra colon before the message.

On the other hand, Gradle's Java compiler uses a multi-line format. It looks fairly different from EclipseParser's regex.

Anyway, this means it would be fairly easy to add Kotlin-Gradle support to the "javac" parser, or to the kotlin-maven-plugin parser if it is split out. Still don't know how I'd name either parser though, other than "javac-style" in the former case.

[uhafner]

I think for now we should use your implementation. If some users do not realize that the parser work with Kolin as well, we still can add an additional parser. Maybe I can show the mapping of parsers to compilers in a better way in future versions of the plugin.