The current core packaging values are: pom, jar, maven-plugin, ejb, war, ear, rar. The valid types are Plexus role-hints (read more on Plexus for a explanation of roles and role-hints) of the component role .mapping.LifecycleMapping. When no packaging is declared, Maven assumes the packaging is the default: jar. We could make it into a war by declaring a different packaging: In our case, the example POM for :my-project:1.0 defined above will be packaged as a jar. Now that we have our address structure of groupId:artifactId:version, there is one more standard label to give us a really complete what: that is the project's packaging.
The three elements given above point to a specific version of a project, letting Maven know who we are dealing with, and when in its software lifecycle we want them. my-project version 1.0 files live in the directory structure $M2_REPO/org/codehaus/mojo/my-project/1.0. It is also used within an artifact's repository to separate versions from each other.
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. groupId:artifactId denotes a single project but they cannot delineate which incarnation of that project we are talking about.
Note that the dot-notated groupId does not have to correspond to the package structure that the project contains. Group ID's do not necessarily use the dot notation, for example, the junit project. For example, all core Maven artifacts do (well, should) live under the groupId.
The POM defined above is the bare minimum that Maven allows. This is unlike a build.xml file, where tasks are almost always dependant on the lines executed before it.
If some external force causes the lifecycle to skip the Ant plugin execution, it does not stop the plugins that are executed from doing their magic. Whereas a build.xml tells Ant precisely what to do when it is run (procedural), a POM states its configuration (declarative). For example, by configuring the maven-antrun-plugin, one can embed Apache Ant tasks inside of the POM. That is not to say that the POM cannot affect the flow of the lifecycle - it can. It is the declarative manifestation of the "who", "what", and "where", while the build lifecycle is the "when" and "how". The POM contains all necessary information about a project, as well as configurations of plugins to be used during the build process. That is currently the only supported POM version, and is always required. This is a listing of the elements directly under the POM's project element. In fact, in the Maven world, a project does not need to contain any code at all, merely a pom.xml. It is a one-stop-shop for all things concerning the project. A project contains configuration files, as well as the developers involved and the roles they play, the defect tracking system, the organization and licenses, the URL of where the project lives, the project's dependencies, and all of the other little pieces that come into play to give code life. When in the presence of Maven folks, speaking of a project is speaking in the philosophical sense, beyond a mere collection of files containing code. It is an XML representation of a Maven project held in a file named pom.xml. The POM 4.0.0 XSD and descriptor reference documentation.Dependency Version Requirement Specification.