I think the -Dno-blah settings have usability issues. As they look at the property name, not the value, you cannot override them or default them with ANT_ARGS or by importing to another ant build file. The way rat.skip does it seems much better using configured value.
Ideally, I would like an easy/fast configuration to set a default for checks that slow up the compilation/test cycle locally to be able to iterate quickly compile and deal with javadoc/checkstyle comments when they're ready to commit, or opt into them on the commandline when needed. e.g. export ANT_ARGS="-Dcheckstyle.default=skip -Djavadoc.default=skip" ant # should just compile, no checkstyle/javadoc etc ant checkstyle # explicitly requested, run checkstyle Similarly I'd like to have the option to configure any CI system I run so all non-execution essential checks run in their own pipeline and fail the build if there's a problem, but still run the other test targets despite violations. Each builder wasted the time running the checks that only need to happen once and you didn't get feedback about your tests that could have run. Of course not everybody may want that and the main Apache Cassandra CI may only want to run tests for checked commits for resource reasons. Also,as a minor nuisance, if you forget the =true as in the examples, ant consumes the next argument as the value, so "ant publish -Dno-tests -Dno-checks" would set no-tests=-Dno-checks and run the checks you tried to skip anyway. Back to the proposal, I like the idea of an explicit check target that runs all checks, I would not personally have the default target run them but think that's fine as long as you can disable them. ant test is an interesting one On Thu, Jul 6, 2023 at 7:30 AM Maxim Muzafarov <mmu...@apache.org> wrote: > 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. > >>>> > >>>> > >>>> >
