Abre a pasta do teu projeto (ou cola um pom.xml) e escreve o comando que lançarias. Aparece cada fase que esse comando percorre, com os goals que correm nela e de onde vem cada um: o que o Maven põe por defeito segundo o packaging, o teu pom, o parent ou um perfil. Clica num goal para ver a sua origem e a sua linha do pom.
O cálculo foi contrastado goal a goal com o que o Maven imprime a sério (3.10 e 4.0) em onze casos: Spring Boot, multimódulo, WAR, Quarkus, Micronaut, Apache Commons, -pl -am, verify e goals isolados. O que não pode saber (um parent teu que não abriste, um plugin que não conhece) não o inventa: diz-te.
A revisão do pom avisa do que quebra ou muda o build ao passar para o Maven 3.10 ou 4 (um plugin ou uma dependência duplicados já paravam o build; um plugin sem versão muda por si só), e das versões repetidas entre módulos. Tudo está medido contra o Maven a sério. Com o Gradle não se pode ler o build.gradle, porque é código: cola a saída de ./gradlew build --dry-run e sai a ordem real das tarefas, com o seu equivalente em Maven.
A fase por defeito de cada goal e o que os parents habituais trazem (Spring Boot, Apache, Micronaut, JBoss…) vêm do Maven Central, que não se pode consultar a partir do navegador. Vêm incluídos na tool, com data 2026-10-25. Se o teu parent for mais recente, usa-se o mais próximo e avisa-se.