maven transitive dependency rules

I have been using maven for a long time (2 years), and some details that need attention are summarized below:
Scenario 1:
learn-1 pom.xml

<dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-core</artifactId>
     <version>4.1.4.RELEASE</version>
     <!--Depends on the version of commons-logging 1.2-->
</dependency>
<dependency>
      <groupId>com.learn</groupId>
      <artifactId>learn2</artifactId>
      <version>0.0.1-SNAPSHOT</version>
      <!--Depends on the version of commons-logging 1.1.3-->
      <optional>true</optional>     
</dependency>

learn-2 pom.xml

<dependency>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
     <version>1.1.3</version>
</dependency>
<dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>3.8.1</version>
     <scope>test</scope>
</dependency>

mvn dependency:tree View dependencies separately:

[INFO] com.learn:learn2:jar:0.0.1-SNAPSHOT
[INFO] +- commons-logging:commons-logging:jar:1.1.3:compile
[INFO] \- junit:junit:jar:3.8.1:test
[INFO] ------------------------------------------------------------------------

[INFO] com.learn:learn1:jar:0.0.1-SNAPSHOT
[INFO] +- org.springframework:spring-core:jar:4.1.4.RELEASE:compile
[INFO] |  \- commons-logging:commons-logging:jar:1.2:compile
[INFO] +- com.learn:learn2:jar:0.0.1-SNAPSHOT:compile
[INFO] \- junit:junit:jar:3.8.1:test
[INFO] ------------------------------------------------------------------------

Conclusion:
The spring-core in the learn1 module depends on the 1.2 version of common-logging, learn1 depends on learn2, and learn2 also depends on common-logging, and the version number is 1.1.3. Then finally learn1 will depend on the 1.2 version of commons-logging. For indirect dependencies in maven, whichever dependency is defined in the pom file is in the front, the one defined in the previous one is used. spring-core is defined in front of learn2, then learn1 will depend on the version of common-logging1.2. If the order of spring-core and learn2 is changed, the version of commons-logging1.1.3 will be used.
Scenario two:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <!-- Version 1-->
    <version>2.0.6</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <!-- Version 2-->
    <version>4.1.4.RELEASE</version>
</dependency>

Analysis results:

[INFO] com.learn:learn1:jar:0.0.1-SNAPSHOT
[INFO] +- org.springframework:spring-core:jar:4.1.4.RELEASE:compile
[INFO] |  \- commons-logging:commons-logging:jar:1.2:compile

Conclusion:
learn1 will depend on the spring-core dependency of the version 4.1.4.RELEASE declared later. A Pom file declares the dependency on the high and low versions of a project, using the last declarer.
Scenario 3:
learn-1 depends on the project learn-2, learn-3, learn-2 depends on commons-logging: version 1.1.3, learn-3 depends on learn-4, and learn-4 depends on commons-logging: version 1.2. Then the final commons-logging version that learn-1 depends on will be version 1.1.3. This is because maven adopts the shortest path first principle

Scenario
four (optional): learn5 pom.xml

<dependency>
       <groupId>commons-logging</groupId>
       <artifactId>commons-logging</artifactId>
       <version>1.2</version>
       <optional>true</optional>
</dependency>

learn6 pom.xml

<dependency>
     <groupId>com.learn</groupId>
     <artifactId>learn5</artifactId>
     <version>0.0.1-SNAPSHOT</version>
</dependency>

Analysis results:

[INFO] com.learn:learn6:jar:0.0.1-SNAPSHOT
[INFO] \- com.learn:learn5:jar:0.0.1-SNAPSHOT:compile

If learn5 commented out the optional tag of commons-logging, the results of the analysis will be different.
Analysis results:

[INFO]
com.learn:learn2:jar:0.0.1-SNAPSHOT
[INFO] \- com.learn:learn1:jar:0.0.1-SNAPSHOT:compile
[INFO]    \- commons-logging:commons-logging:jar:1.2:compile

Conclusion:
If the optional tag is set to true, it means that the submodule will not depend on this module. If you want to depend on this jar, you must declare it in your own pom.xml file. The official documentation says: This is done to avoid problems with the wrong jar violating the license or problems with the classpath.
Friendly reminder:
If there is a problem with our project dependencies, please use mvn dependency:tree to check the dependencies.
Attach a mvn plugin link http://maven.apache.org/plugins/index.html for us to learn or solve our practical problems.