Great stuff, Josh! This is what I was talking about when I was mentioning that I am super curious about the workflows of other people. Any chance you share your setup somewhere so I may try it? Too soon to tell if we indeed want to go that direction but trying it out would be great ....
________________________________________ From: Josh McKenzie <jmcken...@apache.org> Sent: Thursday, June 29, 2023 20:44 To: dev Subject: Re: [DISCUSS] When to run CheckStyle and other verificiations NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. In accord I added an opt-out for each hook, and will require such here as well On for main branches, off for feature branches seems like it might blanket satisfy this concern? Doesn't fix the "--atomic across 5 branches means style checks and build on hook across those branches" which isn't ideal. I don't think style check failures after push upstream are frequent enough to make the cost/benefit there make sense overall are they? Related to this - I have sonarlint, spotbugs, and checkstyle all running inside idea; since pulling those in and tuning the configs a bit I haven't run into a single issue w/our checkstyle build target (go figure). Having the required style checks reflected realtime inside your work environment goes a long way towards making it a more intuitive part of your workflow rather than being an annoying last minute block of your ability to progress that requires circling back into the code. >From a technical perspective, it looks like adding a reference >"externalDependencies.xml" to our ide/idea directory which we copied over >during "generate-idea-files" would be sufficient to get idea to pop up prompts >to install those extensions if you don't have them when opening the project >(theory; haven't tested). We'd need to make sure the configuration for each of those was calibrated to our project out of the box of course, but making style considerations a first-class citizen in that way seems a more intuitive and human-centered approach to all this rather than debating nuance of our command-line targets, hooks, and how we present things to people. To Berenguer's point - better to have these be completely invisible to people with their workflows and Just Work (except for when your IDE scolds you for bad behavior w/build errors immediately). I still think Flags Are Bad. :) On Thu, Jun 29, 2023, at 1:38 PM, Ekaterina Dimitrova wrote: Should we just keep a consolidated for all kind of checks no-check flag and get rid of the no-checkstyle one? Trading one for one with Josh :-) Best regards, Ekaterina On Thu, 29 Jun 2023 at 10:52, Josh McKenzie <jmcken...@apache.org<mailto:jmcken...@apache.org>> wrote: I really prefer separate tasks than flags. Flags are not listed in the help message like "ant -p" and are not auto-completed in the terminal. That makes them almost undiscoverable for newcomers. Please, no more flags. We are more than flaggy enough right now. Having to dig through build.xml to determine how to change things or do things is painful; the more we can avoid this (for oldtimers and newcomers alike!) the better. On Thu, Jun 29, 2023, at 8:34 AM, Mick Semb Wever wrote: On Thu, 29 Jun 2023 at 13:30, Jacek Lewandowski <lewandowski.ja...@gmail.com<mailto:lewandowski.ja...@gmail.com>> wrote: There is another target called "build", which retrieves dependencies, and then calls "build-project". Is it intended to be called by a user ? If not, please follow the ant style prefixing the target name with an underscore (so that it does not appear in the `ant -projecthelp` list). If possible, I agree with Brandon, `build` is the better name to expose to the user.
