There is a separate thread started and respective ticket for generate-idea-files. https://lists.apache.org/thread/o2fdkyv2skvf9ngy9jhpnhvo92qvr17m CASSANDRA-18467
On Thu, 29 Jun 2023 at 16:54, Jeremiah Jordan <jeremiah.jor...@gmail.com> wrote: > +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. >> >> >> >>
