Hi there Robert, Yes, you did work with me, but the solution to add my custom versions of jars that I want to test with, into the `DependencyConstraints` file just feels like the wrong approach. The prior art you refer to, is a specific version of tomcat we want each module to use. It is no different to specifying the exact artifact version we want for production code. My case is that I don’t want my artifact version dependencies to leak outside of the test module.
I think, the fact that the decision to elevate spotless from cosmetic formatter to actually having a significant impact, was done unilaterally. Please don’t get me wrong, I love the fact that we want to fix the problem where developers are not following good practices. But I think I am digging in here, because I believe we missed an opportunity to get more voices in this decision. I also firmly believe that spotless is overstepping the “cosmetic” boundary. I think many developers would feel upset if their code were to be changed. If spotless suddenly replaces a for-loop with a stream implementation. I think it is one thing to decide if gradle should be formatted with 2 spaces vs 4, or when and how lines wrap, and it’s another for spotless to just remove version information and force one consistent version even if the version was specifically overriden. I wonder if we can maybe reduce the area of effect of this change and really only force the version formatter to activate for the ‘main’ configuration and leave every other configuration type (test, distributedTest, integrationTest, acceptanceTest, upgradeTest) alone. --Udo From: Robert Houghton <rhough...@vmware.com> Date: Tuesday, October 12, 2021 at 10:38 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Currently there is no way to exclude certain code blocks from the malicious code formatter. Therefore, my tests that require a specific hardcoded version of Spring to be used, will always either fail the validation or tests will fail due to spotless changing my testing scenario by affecting the version of the library that we have to use. Udo, I have worked with you to accomplish your goal of not automatically “fixing” the inclusion of dependency versions in the build files, as your work case wants to do something special there. The formatter now throws when there is a naked version-string on the dependency line, as we discussed. If you want to continue to work around this, there are many cases of prior art in Geode, such as extensions/geode-modules-tomcat9/build.gradle, where specific versions are allowed. Good luck. -Robert Houghton
