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
OS independent call to applyStyle #313
Conversation
Problem: While working on a Windows system the supplied linux script applyStyle.sh won't work Solution: OS independent call to applyStyle using gradle features, JavaExec could be used to call the google-java-format.jar directly (supplied change) Alternative: could be a Wndows batch script simulating the linux script and a gradle if (Os.isFamily(Os.FAMILY_WINDOWS) .... to call the *.bat instead of *.sh My preference is JavaExec.
Can't you run the |
@thias15 , no gradlew.bat won't work as it currently try's to call utils/applyStyle.sh (which will not execute on Windows). Output: Here are the highlights of this release:
For more details see https://docs.gradle.org/7.1.1/release-notes.html Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0. You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins. See https://docs.gradle.org/7.1.1/userguide/command_line_interface.html#sec:command_line_warnings BUILD SUCCESSFUL in 8s Regarding the performance, I can't compare (from the example you see it took 8s with JavaExec) |
Tested on Mac, there it fails. Will test on Linux and Windows when I get a chance.
This points to a problem with the Java version, but on master it works fine. |
Good, thx, P.S. a general possible problem with both (JavaExec and the shell script) could be (possibly in future), that applyStyle always goes through all *.java source files which ends up in a pretty long argument list for the call to the jar (but this general issue has nothing to do with the failure on Mac, where I agree is likely some Java version issue). |
function as before, just removed the not deeded convert of Filetree to list and let gradle use directly use the source file name (without not needed toString() call.
Sorry for the delay. With the correct Java version setup it works fine. Thanks! How about doing something similar for |
Tried it already also for 'checkStyle' but didn't find a way to cope current output, problem was/is that the script uses the java exitcode to output different text and I haven't found a way (there is currently no way) to catch the exitcode within the gradle task to do something similar.
Here the code: -----start code in build.gradle--------------------
} Example 1 with simulated wrong format in one File
Execution failed for task ':checkStyle'.
Example 2 output with all files with correct style
Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0. You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins. See https://docs.gradle.org/7.4/userguide/command_line_interface.html#sec:command_line_warnings BUILD SUCCESSFUL in 1s I've no better idea as going to all .java files, as gradle doesn't currently offer a way to work only on modified files (have read it's on their todo list). As long as the command-line length limit is not exeeded the current way is performance wise good. |
Above looks good. Locally, even having just |
Workflow works fine. Can you double-check that both |
On windows both work fine.
will do it right now. |
…applystyle # Conflicts: # android/build.gradle
reapplied the collorcode apply JavaExec to applyStyle, as fallback keep both renamed shell script based tasks as checkStyleUnix and applyStyleUnix
Problem: While working on a Windows system the supplied linux script applyStyle.sh won't work
Solution: OS independent call to applyStyle using gradle features, JavaExec could be used to call the google-java-format.jar directly (supplied change)
Alternative: could be a Wndows batch script simulating the linux script and a gradle if (Os.isFamily(Os.FAMILY_WINDOWS) .... to call the *.bat instead of .sh
The content of the applyStyle.bat file could be
for /R ../app/src/main/java/org/openbot %%f in (.java) DO (java -jar google-java-format-1.7-all-deps.jar -r %%f)
My preference is JavaExec.