Spotless Maven apply should be bound to a phase by default #1135
Comments
aaime
changed the title
|
Hi @aaime, I investigated this problem using your branch mentioned in the previous issue: https://github.com/aaime/geoserver/tree/spotless-wtp. I think setting the default phase for Note the Direct plugin invocations seem to be problematic because they rely on the Note the I think we can’t teach Spotless resolve We could bind <plugin>
<groupId>com.diffplug.spotless</groupId>
<artifactId>spotless-maven-plugin</artifactId>
<version>${spotless.version}</version>
<executions>
<execution>
<id>apply-id</id>
<!-- <phase>process-sources</phase> --> <!-- no need for this line -->
<goals>
<goal>apply</goal>
</goals>
</execution>
</executions>
</plugin>Any thoughts or input much appreciated :) |
|
Let me go back to the question that triggered this report then: is there a way to use the Spotless with WTP in a multi-module maven project, having multiple nesting levels, so pretty much needing an absolute reference to the configuration file? The main difference between spotless and checkstyle is that we run spotless in every build, to reformat the files, while checkstyle is only used when specifically invoked (part of the QA profiles) because it would take too much time. In other words, we should not ask developers to enable a profile for something that should always be done. |
|
Hi @aaime, It is not possible to inline the formatter config into the pom. Spotless maven plugin supports multi-module projects but the project structure requires a bit of additional configuration. You could follow this guide for PMD plugin multi-module configuration or take a look at #210 file Please let us know if this suggestion works for you 🙏 Perhaps we need a new documentation section explaining multi-module setup with concrete examples 🤔 |
after moved to parent project, running `./mvnw clean verify`, project will be built correctly but if changed to use `./mvnw spotless:apply`, it will throw the following error ``` No plugin found for prefix 'spotless' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (C:\Users\Joseph\.m2\repository), central (https://repo.maven.apache.org/maven2)] ``` Running `./mvnw -pl starter-mvc-core spotless:apply`would be fine though To fix root cause, the fix, it seem, is to ensure submodules point to the parent pom.xml See diffplug/spotless#1135 Reference https://kurular4.medium.com/why-you-should-use-parent-pom-for-your-multi-module-java-projects-b575017fab2e
* initiate converting to maven multi-module structure * move spotless plugin to parent project after moved to parent project, running `./mvnw clean verify`, project will be built correctly but if changed to use `./mvnw spotless:apply`, it will throw the following error ``` No plugin found for prefix 'spotless' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (C:\Users\Joseph\.m2\repository), central (https://repo.maven.apache.org/maven2)] ``` Running `./mvnw -pl starter-mvc-core spotless:apply`would be fine though To fix root cause, the fix, it seem, is to ensure submodules point to the parent pom.xml See diffplug/spotless#1135 Reference https://kurular4.medium.com/why-you-should-use-parent-pom-for-your-multi-module-java-projects-b575017fab2e * move maven-toolchains to parent pom * move maven-enforcer to parent pom fix an issue where requireJavaVersion is not enforced, which is caused by having multiple <rules>, it only requires a single <rules> * move maven-site to parent pom When running mvn site on a top level project, Maven will build all sites for every module defined in the modules section of the pom individually. Note that each site is generated in each individual project's target location. As a result, relative links between different modules will NOT work. They will however work when you deploy or stage the site. See https://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.html Note that https://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.html#aggregate-reports is not configured yet * move versions-maven to parent pom when running command from parent pom, it will scan through parent and all sub-modules to update the pom.xml, if want to scan specify pom.xml then run with -pl <module> command See https://stackoverflow.com/questions/4146638/maven-variable-for-reactor-root/48879554#48879554 for using ${session.executionRootDirectory} as the root directory of where .mvnw is ran See https://cwiki.apache.org/confluence/display/MAVEN/Maven+Properties+Guide for a standard maven variables * move git-commit-id-maven to parent pom when run `./mvnw verify`, the sub-modules will run the git info and generate in its build directory * move modernizer-maven to parent pom Possible to suppress via annotation, see https://github.com/gaul/modernizer-maven-plugin#ignoring-elements when run `./mvnw verify`, the sub-modules will run the modernizer * move spotbugs to parent pom adds spotbugs reporting to submit when running ./mvnw site however, spotbugs report is not reporting on parent site project but is reporting at the sub-module * move maven-pmd to parent pom * move jacoco-maven to parent pom thinking if jacoco should exist in its own sub-module but still leave it at parent pom first * move java.version properties to parent pom * move jacoco and git-commit-id-maven to pluginManagement section Placing in pluginManagement kind of allowing to centalize the configuration but not taking effect on any modules until any of the module declare this in the plugin section on their pom.xml See https://www.baeldung.com/maven-plugin-management * polish pom.xml
I think binding to the process-sources phase by default is a good choice |
I have a multi-module Maven project that contains a number of XML files, which I'd like to format with the WTP formatter, using a custom configuration for it. The configuration file resides in a top-level directory.
Here is a snipped of the Maven pom file:
Trying to run
mvn spotless:applyfails because the geoserverBaseDir is not initialized. I've been told in other reports this is likely happening because the SpotlessApplyMojo is not bound to a default phase, unlike for example the SpotlessCheckMojo.The
process-sourcesphase seems like it would be a good candidate for a default phase? Here is the reference to all phases.Reference versions and OS:
The text was updated successfully, but these errors were encountered: