Bombya Bo,
Think of Maven build life cycle like a fancy meal which has sequential phases:
- starter (resources)
- main (compile)
- dessert (package)
- coffee (install)
- digestif (deploy)
A goal is the actual food being served during that phase.
- starter: gazpacho
- main: steak; gravy; fries
- dessert: tiramisu
- coffee: cappuccino
In this analogy:
- pom.xml file is the equivalent of today's menu written on the chalk board
- calling
mvn
on the command line is the equivalent of placing your order to the waiter
- you can have more than one item of food/goal bound to a single phase (steak+gravy+fries)
If you like the house defaults, then you can just order the first N courses off the fixed menu:
"I'll take the 2 course meal"
$ mvn compile
You'll get everything up to and including the main course (ie gazpacho followed by steak+gravy+fries).
Calling a single goal is the equivalent of ordering a la carte:
"I'll take a Cobb salad plus the 2 course meal"
$ mvn javadoc:javadoc compile
If you want that goal to become a permanent addition to the menu, then add it to the pom file. That brings us back to calling:
$ mvn compile
which results in gazpacho+Cobb, followed by steak+gravy+fries.
A last point about binding a goal to a phase.
By default, each goal will run during a certain phase (Cobb salad usually served as a starter).
But you can override the phase binding, which is like telling the waiter "I'll have a Cobb salad, but bring it at the same time as the main"
Hope this clarifies the intuition behind goals vs. phases.