It is impossible for maven to work without defining versions of the
artifacts , so somewhere it must be mentioned, lets dig in part by
part.
All pom.xml
s are logically inherit from the super POM. You can always see what your "real" pom.xml
looks like by typing:
mvn help:effective-pom
The resulting pom.xml
that is printed is a combination of the super POM, your pom.xml, and any parent POMs in the mix as well.
Note from Maven 3 the super POM does not contain any of the (default lifecycle) plugins versions but earlier till Maven 2 it used to have.
The Maven 3 super POM is provided by the org.apache.maven.model.superpom.DefaultSuperPomProvider
class https://github.com/apache/maven/blob/bce33aa2662a51d18cb00347cf2fb174dc195fb1/maven-model-builder/src/main/java/org/apache/maven/model/superpom/DefaultSuperPomProvider.java#L56-L85
The resource it loads can be found here: https://github.com/apache/maven/blob/bce33aa2662a51d18cb00347cf2fb174dc195fb1/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L23-L149
Edit:
As per Maven Coordinates
groupId
:artifactId
:version
are all required fields (although,
groupId and version need not be explicitly defined if they are
inherited from a parent - more on inheritance later). The three fields
act much like an address and timestamp in one. This marks a specific
place in a repository, acting like a coordinate system for Maven
projects:
version: This is the last piece of the naming puzzle. groupId
:artifactId
denotes a single project but they cannot delineate which incarnation of that project we are talking about. Do we want the junit:junit of 2018 (version 4.12), or of 2007 (version 3.8.2)? In short: code changes, those changes should be versioned, and this element keeps those versions in line. It is also used within an artifact's repository to separate versions from each other. my-project version 1.0 files live in the directory structure $M2_REPO/org/codehaus/mojo/my-project/1.0.