Thinking about this more, I agree the right phase should be on both process-resources and process-test-resources respectively (though a bit surprising for users indeed).
On the way it should operate: I was going to propose a CI-only flag to fail there when a format is not good, but to avoid the CI surprise, I'm thinking the standard build should: * Detect a formatting change need, do it, and non-zero exit Or * Detect no formatting need and do nothing This way the behavior is the same locally and in Jenkins, and it should not be too disruptive as it's not very late in the Maven lifecycle. I think non-zero exiting is useful locally, so you don't end up git add & commit, mvn test, git push but then get a CI failure because you had a local formatting change you didn't add before pushing. Le mar. 24 juil. 2018 à 22:44, Liam Newman <[email protected]> a écrit : > The auto format should occur before the compile stage, probably during > process-sources > > > > On Tue, Jul 24, 2018, 6:00 AM Baptiste Mathus <[email protected]> wrote: > >> Great idea and initiative IMO, thanks a bunch for driving this Mark. >> >> Over the years, I've become more and more strongly opinionated that *a* >> common format is defined, and easily applied, and less and less about the >> precise format. >> IOW, I generally do have opinions about where curly brackets and others >> should go, but I'll happily put them aside if this helps us define >> *something*. >> >> @Mark you can use https://github.com/jenkinsci/buildtriggerbadge-plugin >> or https://github.com/jenkinsci/essentials-plugin and few others to test >> drive this. >> https://github.com/jenkinsci/radiatorview-plugin might also be >> interesting as it has a bit more code, and has been existing for quite long >> I think. >> >> -- Baptiste >> >> >> >> Le mar. 24 juil. 2018 à 03:36, Mark Waite <[email protected]> a >> écrit : >> >>> I'd like to submit a Jenkins Enhancement Proposal for optional automated >>> source code formatting available from the plugin pom so that plugins which >>> build with maven could choose to "opt-in" to automated source code >>> formatting. >>> >>> Key attributes of the idea: >>> >>> - *Optional* - plugins only get source code formatting if they >>> enable it >>> - *Automatic* - when source code formatting is enabled, it happens >>> automatically as part of the maven compile phase >>> - *Common* - when source code formatting is enabled, the source code >>> formatting settings are not intended to be altered by the plugin >>> >>> I've implemented a sample in the platformlabeler plugin >>> <https://github.com/jenkinsci/platformlabeler-plugin/blob/fcae9d81f557c4fdcb1b991487e28113f718a81d/pom.xml#L76> >>> using the "FMT Maven plugin >>> <https://mvnrepository.com/artifact/com.coveo/fmt-maven-plugin>" which >>> uses google-java-format <https://github.com/google/google-java-format> >>> to format Java source code to Google Java Style >>> <https://google.github.io/styleguide/javaguide.html>. >>> >>> Key questions that need discussion (especially considering my feeble >>> skills with maven): >>> >>> - Is optional automated source formatting of interest to a few >>> plugin developers that would be willing to test drive it? If so, who are >>> the plugin developers that are willing to test drive it, and which >>> plugins >>> will be involved in the test drive? I'll use platformlabeler as one of >>> the >>> test drive plugins. Others will be needed >>> - How would a prototype of optional automated source formatting be >>> evaluated? By releasing a beta version of the plugin parent pom >>> >>> <https://github.com/jenkinsci/plugin-pom/blob/8224b204a5646d4292da7b3e38876ca6fbde9c33/pom.xml#L580>? >>> Some other means? >>> - Would automated formatting be integrated into the plugin parent >>> pom using techniques similar to the findbugs integration >>> >>> <https://github.com/jenkinsci/plugin-pom/blob/8224b204a5646d4292da7b3e38876ca6fbde9c33/pom.xml#L580> >>> into the plugin parent pom, or is there a better way? >>> - Is "google java format" an acceptable code format for those plugin >>> authors that are willing to adopt automated code formatting? >>> - Are there other issues that need to be addressed before a Jenkins >>> Enhancement Proposal is submitted for optional automated source code >>> formatting? >>> >>> A plugin maintainer that chooses to adopt automated source code >>> formatting needs to understand that automated source code formatting >>> creates a "diff wall" due to the many changes made by the formatting >>> process. That is one of the penalties associated with automated source >>> code formatting. >>> >>> Plugins with many open pull requests (git plugin, git client plugin) >>> should not enable automated formatting until they've reduced the number of >>> open pull requests to very few. Otherwise, most open pull requests for the >>> plugin will have many conflicts as soon as the automated formatting is >>> committed. That is another of the penalties of automated source code >>> formatting. >>> >>> Plugins that adopt automated source code formatting will likely find it >>> easier to read the source code and easier to submit clean pull requests. >>> Automated formatting avoids the poor experience of pull request submitters >>> being asked to fix the white space diffs introduced by their pull request. >>> >>> Thanks, >>> Mark Waite >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtExx4tXNbAVCSr85jPDTKR1Zy_BJrxkcp_kJdAfcVaZgQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtExx4tXNbAVCSr85jPDTKR1Zy_BJrxkcp_kJdAfcVaZgQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4oBgvoAZnWDh8Fw9HfNATZFcrg3ZDKm4m0LwLYWti7Ew%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4oBgvoAZnWDh8Fw9HfNATZFcrg3ZDKm4m0LwLYWti7Ew%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNwGXcwroH95QyCORW4cYXx8h0BsUiLO4NwAZtF2Vh2Siw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNwGXcwroH95QyCORW4cYXx8h0BsUiLO4NwAZtF2Vh2Siw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5s_1jy33-pPrpt3Hu29Q%2B6fyd9GRZ4JEaAR-Ji%2BZBz4g%40mail.gmail.com.
