In my humble opinion, it is better to have only one plain and straightforward build pipeline for the whole project, with custom flags used to skip a particular step, than to have multiple pipelines under the ant tool with multiple endpoints accordingly. I mean, all the steps need to be lined up, with each step in the pipeline executing everything that stands before it unless skip flags are specified. Meanwhile, I like your idea of grouping all the checks under the dedicated step (and changing the no-checkstyle flag to no-checks accordingly as Ekaterina mentioned).
Let me share a simple example of what I'm talking about with one single endpoint. Let's assume the following step order: init -> _build_java (compile) -> checks -> build -> jar -> test -> artifacts -> publish; So, the use would be: ant jar -Dno-checks ant test -Dno-build ant publish -Dno-tests -Dno-checks I'm not saying what you've proposed is bad, in fact, we're not currently doing the pipeline I'm talking about, but adding an additional endpoint is something we should consider very carefully as it may create some difficulties for Maven/Gradle migration if it ever happens. So, if I'm not mistaken the following you're trying to add a new endpoint to the way how we might build the project: - "ant [check]" = build + all checks (first endpoint) - "ant jar" = build + make jars + no checks (second endpoint) And I would suggest running `ant jar -Dno-checks` instead to achieve the same result assuming the `jar` is still transitively dependent on `checks`. On Thu, 6 Jul 2023 at 14:02, Jacek Lewandowski <lewandowski.ja...@gmail.com> wrote: > > 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. >>>> >>>> >>>>
