Issues running on Windows

[rocketraman]

Ok, I don't use Windows myself (ugh), but some of my coworkers do. There are issues running this on Windows:

1. The compiler is run with an invalid path that contains a leading "/". Here is the debug output from Gradle:

11:48:22.846 [INFO] [org.gradle.process.internal.DefaultExecHandle] Starting process 'command 'C:\jdk1.8.0_191\bin\java.exe''. Working directory: H:\source\myproject\lib-proto Command: C:\jdk1.8.0_191\bin\java.exe -Dfile.encoding=windows-1252 -Duser.country=US -Duser.language=en -Duser.variant -jar /C:/Users/Me/.gradle/caches/modules-2/files-2.1/com.github.marcoferrer.krotoplus/kroto-plus-compiler/0.1.3/620b2a278b4d4beed80320bb4800339967f850d7/kroto-plus-compiler-0.1.3.jar H:\source\myproject\lib-proto/src/main/proto H:\source\myproject\lib-proto\build/extracted-include-protos/main -default-out H:\source\myproject\lib-proto\build\generated\source\proto\main\kotlin -writers 3 -StubOverloads -o|H:\source\myproject\lib-proto\build\generated\source\proto\main\kotlin|-coroutines -MockServices -o|H:\source\myproject\lib-proto\build\generated\source\proto\main\kotlin -ProtoTypeBuilder
...
11:48:22.874 [ERROR] [system.err] Error: Unable to access jarfile /C:/Users/Me/.gradle/caches/modules-2/files-2.1/com.github.marcoferrer.krotoplus/kroto-plus-compiler/0.1.3/620b2a278b4d4beed80320bb4800339967f850d7/kroto-plus-compiler-0.1.3.jar

Note the leading slash on the -jar argument.

2. I don't know if this is an issue in this plugin or in the upstream protobuf gradle plugin, but when adding the kroto code gen plugin to the protobuf plugin, the build fails with the error:

Execution failed for task ':generateProto'.
> protoc: stdout: . stderr: --kroto_out: protoc-gen-kroto: %1 is not a valid Win32 application.

Looking at the --debug logs, it looks like a --plugin parameter is addd to the call to protoc, with the following value:

 --plugin=protoc-gen-kroto=C:\Users\Me\.gradle\caches\modules-2\files-2.1\com.github.marcoferrer.krotoplus\protoc-gen-kroto-plus\0.1.3\3c41d071d04c8558822447643894490e33a857b7\protoc-gen-kroto-plus-0.1.3-jvm8.jar

but protoc is assuming the jar file is an executable it can run. I have tried associating ".jar" files with "java" (and this seems to have worked), but for some reason when running via protoc, the same "not a valid Win32 application" error still happens.

[rocketraman]

This might be related to the second item mentioned above: google/protobuf-gradle-plugin#268

[marcoferrer]

It looks like the problem is that the script thats embedded in the jar via spring boot is not executable in windows. I dont think there is any issue with the gradle protobuf plugin.

The fix is probably going to involved distributing another artifact that is executable on windows. I dont have any way to test it out at the moment. But I think if you point the protobuf gradle plugin to an executable bat script that executes the jar via java it might work in mean time. This will give me a chance to work on the long term solution. I dont have much experience with windows batch scripts but try this if possible

@if "%DEBUG%" == "" @echo off

set CMD_LINE_ARGS=%*
set JAVA_HOME=%JAVA_HOME:"=%
set JAVA_EXE=%JAVA_HOME%/bin/java.exe

"%JAVA_EXE%" -jar C:\Users\Me\.gradle\caches\modules-2\files-2.1\com.github.marcoferrer.krotoplus\protoc-gen-kroto-plus\0.1.3\3c41d071d04c8558822447643894490e33a857b7\protoc-gen-kroto-plus-0.1.3-jvm8.jar %CMD_LINE_ARGS%

build.gradle

protobuf {
  protoc {
    artifact = 'com.google.protobuf:protoc:3.6.1'
  }
  plugins {
    kroto {
      path = "absolute/path/to/script.bat"
    }
  }
  ...
}

If that works then I can come up with a gradle task to hold you over in the mean time.

[rocketraman]

@marcoferrer Thanks, the batch script solves works around problem 2. However, the build gets further and still encounters problem 1. The specific error is:

18:36:04.214 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process 'command 'C:\jdk1.8.0_191\bin\java.exe''
18:36:04.214 [DEBUG] [org.gradle.process.internal.ExecHandleRunner] waiting until streams are handled...
18:36:04.235 [ERROR] [system.err] Error: Unable to access jarfile /C:/Users/Me/.gradle/caches/modules-2/files-2.1/com.github.marcoferrer.krotoplus/kroto-plus-compiler/0.1.3/620b2a278b4d4beed80320bb4800339967f850d7/kroto-plus-compiler-0.1.3.jar

I think that leading slash is the issue.

[marcoferrer]

Whats confusing for me is that the snippet you posted is referencing the old stand alone compiler "kroto-plus-compiler-0.1.3.jar" and not the protoc plugin "protoc-gen-kroto-plus-0.1.3-jvm8.jar" . If your using the kroto-plus gradle plugin for 0.1.3 you can disable it. If possible can you post a snippet of your gradle config?

[rocketraman]

Aha, looks like I still had a krotoPlus { ... } block from an earlier version. I've removed it and gotten everything working properly on Linux again. Now on to the next Windows issue:

Execution failed for task ':generateProto'.
> protoc: stdout: . stderr: \source\myproject\krotoPlusConfig.json:H:\source\myproject\build/generated/source/proto/main/java/: No such file or directory

The krotoplus config is:

outputSubDir = "java"

I've used the --debug output to obtain the actual protoc command line, and the argument passed was as follows:

--kroto_out=ConfigPath=H:\source\myproject\krotoPlusConfig.json:H:\source\myproject\build/generated/source/proto/main/java

so you can see that the first : in H: is being mistaken for the separator between the config and output directory, which is why it is looking for directory \source\myproject\krotoPlusConfig.json:H:\source\myproject\build/generated/source/proto/main/java/. If I manually edit the argument to look like this:

kroto_out=ConfigPath=\source\myproject\krotoPlusConfig.json:H:\source\myproject\build/generated/source/proto/main/java

then the protoc command exits without an error. Note the second H: after the : delimiter does seem to be necessary -- oddly, removing the second H: results in another No such file or directory error.

[rocketraman]

A workaround seems to be to do this to relativize the config path before passing it to protoc:

option "ConfigPath=${file('.').toPath().toAbsolutePath().relativize(krotoConfig.toPath().toAbsolutePath()).toString()}"

Messy, but it seems to work.

UPDATE: Use file(System.getProperty("user.dir")) instead of file('.') -- see below.

[marcoferrer]

If this can hold you over in the mean time I can work on getting better windows support into an upcoming release.

[rocketraman]

If this can hold you over in the mean time I can work on getting better windows support into an upcoming release.

Yup, it can! I've got workarounds for all issues identified. Looking forward to the next release.

[marcoferrer]

So I think I have a good solution to this problem but wanted to hold off on releasing it too early. I didnt want to hold up the coroutines update but the next release after that should have something in it to address this.

[marcoferrer]

@brandmooffin as per our convo, You can use the documentation from here to implement the windows support outlined in this issue. deployment-script-customization

[marcoferrer]

@brandmooffin We can try doing what the maven protobuf plugin does and wrap the jar using this.
https://github.com/poidasmith/winrun4j