Not sure it is that important since at the end it will fail but from my experience, bypassing it during the dev (ie being bound late) is nicer cause you iterate faster. That said we can PR to make it "failAtEnd", would be good anyway
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Le dim. 1 déc. 2024 à 13:00, Maarten Mulders <mthmuld...@apache.org> a écrit : > +1 to make it part of the Maven build, either in validate or in verify > phase. I usually do this in work projects, too. As Eliotte says, it > avoids breaking the build in CI. Preferably enabled by default, also on > local builds. > > > The only thing where I doubt is whether validate or verify would be a > good phase. > > Reasons for validate: early feedback on formatting, avoids compilation, > testing etc. if the code is not formatted correctly. > Reasons for verify: the important thing is that the code works, > formatting is the last concern. "First make it work, then make it pretty". > > > WDYT? > > > Maarten > > On 29/11/2024 13:27, Elliotte Rusty Harold wrote: > > While working on a third party plugin I noticed it was configured to > > autorun spotless as part of "mvn test" (and probably other goals): > > > > [INFO] --- spotless:2.43.0:apply (default) @ spotbugs-maven-plugin --- > > [INFO] Spotless.Format is keeping 10 files clean - 0 were changed to > > be clean, 0 were already clean, 10 were skipped because caching > > determined they were already clean > > [INFO] Spotless.Format is keeping 182 files clean - 0 were changed to > > be clean, 1 were already clean, 181 were skipped because caching > > determined they were already clean > > [INFO] > > > > We should do that too in our poms to avoid the recurring and annoying > > problems of forgetting to run spotless manually and consequently > > having a meaningless break in the CI that needs to be investigated. > > Integrated over all of us this should save a few days of developer > > time per year. > > > > I'd file a bug, but the way we've set up issue tracking this would be > > one per repo, and I'm disinclined to file the same bug 40 times. Let's > > just do it. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
