1. The order of goals is significant. Goals clean install do not produce the same result as install clean. For example:
$ mvn clean install > /dev/null
$ mvn install clean > /dev/null
2. You might know that you can show the dependency tree with mvn dependency:tree but did you know you can show where in that tree a certain artifact is? This is done by specifying
$ mvn dependency:tree -Dincludes=:spring-context
selectively shows all the dependencies with the artifact of spring-context.
3. If a library appears multiple times but with different versions, Maven re-orders the dependencies based on how deep in the tree they are. From the Apache documentation:
Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.8 it was not defined which one would win, but since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins.
"nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0