Hello again :D In my latest PR I accidentally stumbled <https://github.com/apache/james-project/pull/261#issuecomment-728017295> on a maven command to automatically sort dependencies in `site/src/xdoc/contribute.xml` ``` mvn com.github.ekryd.sortpom:sortpom-maven-plugin:sort -Dsort.keepBlankLines -Dsort.sortDependencies=groupId,artifactId -Dsort.nrOfIndentSpace=4 -Dsort.createBackupFile=false -Dsort.sortModules=true -Dsort.expandEmptyElements=false -Dsort.predefinedSortOrder="recommended_2008_06" ``` After running the command I was left with 153 modified pom files many of which I had not touched, meaning that there is a lot of incorrectly sorted dependencies in the project's pom files.
I suggested creating > mvn compile -Psort To make running the sort plugin easier and help make a transition to a state where the dependencies are all correctly sorted. To which benoit answered <https://github.com/apache/james-project/pull/261> : > And abort the build if needed? => :+1: I looked into this a bit further today, it is easy to make the plugin run and fail the build if a pom is incorrectly sorted. However with 150 invalid pom files in the project this means the build will be blocked for a while unless a massive sorting commit is applied which means probable conflicts for everyone else with currently modified pom in their branch. While I think this remains the best option (because it converges quicker) here are two alternative ideas Create a -P sort profile to help people run the sorting plugin on their repo before committing, they will then have to select the pom they effectively want to commit and revert the rest of the modifications. After a while the most active pom files should be clean and a mass commit on the least active ones should not affect too many people. This however relies on discipline and may never converge. That risk can be mitigated by adding the sorting plugin to the top level pom with a specific execution id and an empty phase, then override that default phase in individual modules which have been sorted. This would result in making the build fail for cleaned up modules yet leave other modules untouched allowing for a progressive cleanup Once the remaining untouched modules are few enough finishing the process with a mass commit on these highly stable modules becomes possible. The mass commit would activate the execution on the compile phase in the top module and remove all the module specific activations. That mass commit affecting the plugin section instead of the dependency section should minimize the risk of conflicts. Let me know what you think and if such a change is desirable jean
