Maven tries download multimodule dependency on `validate` phase

From a build pipeline I want to run validate phase for things like the enforcer plugin. However it does not work for a multimodule project as it tries to download dependencies from repository which are inside the project. However, compile phase does not do that, but for me it is not an option as it is too slow.

pom.xml:

<module>lib</module>
<module>app</module>

lib/pom.xml

 <version>1.2.3</version>

app/pom.xml

 <dependency>
   <artifactId>lib</artifactId>
   <version>1.2.3</version>
 </dependency>

So, if I do mvn compile it works fine.

But if I do mvn validate it fails validating app module as it tries to download lib-1.2.3 from maven repo. For some reason it now could not see that the lib is a neighbour dependency. Why?

I have created a small repo: https://github.com/kan-izh/so63963768

mvn compile

[INFO] --- maven-enforcer-plugin:3.0.0-M3:enforce (enforce-no-snapshots) @ app ---
[INFO]
[INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @ app ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Workspace\repo\so63963768\app\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ app ---
[INFO] No sources to compile
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] parent ............................................ SUCCESS [1.612s]
[INFO] lib ............................................... SUCCESS [1.224s]
[INFO] app ............................................... SUCCESS [0.056s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

mvn validate

[INFO] --- maven-enforcer-plugin:3.0.0-M3:enforce (enforce-no-snapshots) @ app ---
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] parent ............................................ SUCCESS [0.979s]
[INFO] lib ............................................... SUCCESS [0.015s]
[INFO] app ............................................... FAILURE [0.020s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.180s
[INFO] Finished at: Wed Sep 23 11:27:38 BST 2020
[INFO] Final Memory: 7M/34M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M3:enforce (enforce-no-snapshots) on project app: Execution
 enforce-no-snapshots of goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M3:enforce failed: org.apache.maven.shared.dependency.graph.
DependencyGraphBuilderException: Could not resolve following dependencies: [com.so.q63963768:lib:jar:1.2.3 (compile)]: Could not resolve depend
encies for project com.so.q63963768:app:jar:1.2.3: Failure to find com.so.q63963768:lib:jar:1.2.3 in http://xxxxxxxxxxxxx.xx.xxxxxxxxxxxxxxxxx.
com:8081/repository/maven-public/ was cached in the local repository, resolution will not be reattempted until the update interval of nexus has
 elapsed or updates are forced -> [Help 1]

This is a good question, and it shows a small flaw in how Maven handles dependencies.
You need to know that for every plugin-goal you can define if dependencies should be resolved, and for which scope. (and there's a small difference if having only the poms is enough, or that you also need the artifacts)
compiler:compile requires the dependencies that are required during compile, compiler:testCompile requires the dependencies that are required during test.
For the enforce goal it is tricky: the goal itself doesn't require to have resolved dependencies, nor do most rules( like requireJavaVersion or requireMavenVersion), but some rules do, like the one you try to enforce.
Ideally rules can define if they need to have resolved dependencies, but right now the API doesn't support that.

So you have a couple of solutions: always run with compile, or have an execution-block bound to the compile-pahse if it requires artifacts.