-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable java executable #750
Configurable java executable #750
Conversation
The path of the java executable can now be configured in the ProtobufExtension and/or specific GenerateProtoTask instances. * GenerateProtoTask gains the javaExecutablePath Property, * ProtobufExtension gains the javaExecutablePath Property and the defaultJavaExecutablePath provider, which provides the default path using the same logic as previous versions * computeJavaExePath moved from GenerateProtoTask to ProtobufExtension since it is now only used in ProtobufExtension * isWindows moved from GenerateProtoTask to Util since it is now used in GenerateProtoTask and ProtobufExtension
src/test/groovy/com/google/protobuf/gradle/ProtobufJavaPluginTest.groovy
Show resolved
Hide resolved
I think there is a problem with my test when run on Windows, I'm waiting for some feedback from a colleague, but will probably have to add another commit to this PR. |
Is it true that most of the tests will not pass on windows? My colleague reported that a lot more tests failed than I expected. |
I can't say the tests have ever been run on Windows. So, yeah, they could be pretty broken. |
Thank you! |
Thanks folks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test
This feature was discussed in #742. The change allows a user to specify the path to a Java executable in the ProtobufExtension or the GenerateProtoTask, or both, with the task overriding the extension. If the user does not specify any task, the existing behaviour (using the java running gradle) is unchanged.
Since gradle 6.7 there is a much cleaner solution using the configured Java toolchain (see https://docs.gradle.org/current/userguide/toolchains.html#sec:plugins), I did not investigate this option since the plugin currently supports gradle versions back to 5.6.