+100 I support making generate-idea-files auto setup everything in IntelliJ for you. If you post a diff, I will test it.
On this proposal, I don’t really have an opinion one way or the other about what the default is for local "ant jar”, if its slow I will figure out how to turn it off, if its fast I will leave it on. I do care that CI runs checks, and complains loudly if something is wrong such that it is very easy to tell during review. -Jeremiah On Jun 29, 2023 at 1:44:09 PM, Josh McKenzie <jmcken...@apache.org> wrote: > 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> 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> 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. > > > >
