Great discussion, but I feel we still have no conclusion.
I fully support automatically setting up IDE(A) to run the necessary stuff automatically in a developer-friendly environment, but let it be continued in a separate thread. I wouldn't say I like flags, especially if they have to be used on a daily basis. The build script help message does not list them when "ant -p" is run. I'm going to make these changes unless it is vetoed: - "ant [check]" = build + all checks, build everything, and run all the checks; also, this would become the default target if no target is specified - "ant jar" = build + make jars: build all the jars and tests, no checks - All "test" commands = build + make jars + run the tests: build all the jars and tests, run the tests, no checks Therefore, a user who wants to validate their branch before running CI would need to run just "ant" without any args. This way, a newcomer who does not know our build targets will likely run the checks. We still need some flags for skipping specific tasks to optimize for CI, but in general, they would not be required for local development. Flags will also be needed to customize some tasks, but they should be optional for newcomers. In addition, a "help" target could display a list of selected tasks and properties with descriptions. I'd be more than happy if we could conclude the discussion somehow and move forward :) thanks, Jacek czw., 29 cze 2023 o 23:34 Ekaterina Dimitrova <e.dimitr...@gmail.com> napisał(a): > 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. >>> >>> >>> >>>
